What MongoDB taught me about Postgres.

Source: Dev.to

Using MongoDB arguably taught me more about Postgres than using Postgres did.

Hear me out. Previously, my knee‑jerk reaction was to always opt for Postgres when starting a new project. Honestly — a reasonably safe bet. But only using Postgres limited my understanding of it — as well as its benefits and its limitations.

Sounds weird to say I learned more about something by not using it. But it’s true — and that’s why I’m planning this as the first article of a series. Because I genuinely learned so much from not using Postgres.

How did I end up using MongoDB to start with?

My current startup had already opted for MongoDB when I joined. This largely came down to the experience on the ground, as well as the fact that the schema was rapidly evolving. A document‑based database with effectively unlimited schema flexibility was a natural fit.

But this flexibility came at a cost

At first, it was a real joy not having a “migrations‑folder‑of‑death” that harbored the scars of months of schema discovery in hundreds of back‑and‑forth migrations. Schema changes were fast and — when coupled with Pydantic — also continued to ensure a high level of consistency across the codebase.

Nothing broke. The system always continued running. However, it became progressively slower and more expensive. Without rigid schemas, repeated validation was required in application code, not just on writes but also on reads.

When Pydantic validation was happening at scale, the CPU cost in our services became quickly noticeable. This was exacerbated by the fact that our validation relied on full models, limiting the effective use of projection. Simple queries started turning into full‑document reads.

I suddenly began to appreciate the intentional rigidity of Postgres. Keeping validation right next to the data is efficient — not only because it is optimized, but because validation only happens once. Postgres constraints are powerful, turning assumptions into guarantees.

That being said, it’s also nice in a lot of ways to have validation close to the business logic. If we had handled migrations better, the need for defensive and expensive application code could have been reduced. And don’t forget MongoDB schema validation — a feature I under‑utilized.

From my initial joy at the flexibility of MongoDB I quickly learned an important truth: schema discipline doesn’t disappear — but you can choose whether it lives in your application code or in the database.