Why Postgres Made MongoDB Less Special

The NoSQL Revolution That Strengthened SQL

In the early 2010s, MongoDB was everywhere.
Meetups, blog posts, hackathons everyone was saying the same thing:
Forget SQL. Just store JSON and ship faster.

And for a certain kind of project, MongoDB was a breath of fresh air. No schemas, easy to install, and “web scale” (a phrase that became a meme after that infamous video).

But hype doesn’t last forever.

---

What Problem Did MongoDB Solve?

Back then:

• Startups wanted to build fast without getting bogged down in database schema design.

• Developers hated ALTER TABLE migrations just to add a single field.

• The world was moving toward JSON APIs - storing JSON directly made sense.

MongoDB gave you:

• Schema-less storage : Add a new field to your documents without a migration.

• Developer-friendly : Query with a syntax that felt closer to JavaScript than SQL.

• Horizontal scaling : Shard your data across servers to handle large workloads.

A 2011 social media startup could ship features quickly - today you store { name, bio }, tomorrow you add { profilePic } - without touching migrations or breaking existing data.

Where MongoDB Fell Short

The marketing was great. The reality was… mixed.

1. Schema-less ≠ Structure-less
   “No schema” often turned into “no consistency.” You’d end up with {name} in some documents, {fullName} in others, and {n} in a few because someone fat-fingered it.

2. Joins? What Joins?
   MongoDB didn’t do joins well (or at all in early days). If your data was relational - orders, customers, products - you either duplicated data everywhere or wrote ugly aggregation pipelines.

3. Early Durability Issues
   Older MongoDB versions had cases where writes could be acknowledged before hitting disk. That’s not great if you care about not losing money or orders.

4. Sharding Complexity
   Yes, you could scale horizontally - but running and maintaining a sharded Mongo cluster was an ops headache.

How Modern Solutions Beat or Complement It

MongoDB isn’t “dead” like Hadoop hype - it’s still widely used - but it’s no longer the “SQL killer” it was marketed as.

1. Postgres Got JSON

• PostgreSQL added JSON/JSONB columns with indexing, giving you the flexibility of Mongo plus relational power.

• You can store semi-structured data and still run SQL joins when you need them.

2. Managed Mongo (Atlas)

• Atlas fixed some pain points but it’s basically Mongo with training wheels. You’re still dealing with document design pitfalls if you misuse it.

3. Better Fit-for-Purpose Choices

• DynamoDB for massive key-value workloads.

• Elasticsearch for text search.

• Redis for caching.

A Practical Comparison

Old Way (Mongo, 2012):

• Launch MVP fast.

• Add fields freely without migrations.

• Denormalize data for performance.

• Regret it later when analytics and reporting need consistency.

New Way (Postgres with JSONB, 2025):

• Use strict schemas where you need relational guarantees.

• Store flexible JSON for fields that change often.

• Keep queries consistent, indexed, and optimized.

Example

MongoDB’s Original Pitch : "Need to store flexible data like user profiles with different fields for each user? MongoDB lets you add { favoriteFood } to one document and { petName } to another without schema changes."

Now (Postgres with JSONB):
JSONB column: store flexible fields inside a relational table.

• Need favoriteFood for one row? Add it in JSONB.

• Still join on user_id like a normal SQL table.

• Create an index on favoriteFood if needed.

The only reason many teams picked Mongo flexible documents is now built into Postgres, but without sacrificing joins, ACID, or query power.

Where MongoDB Still Works Well

• Rapid prototyping where schema changes daily.

• Event logging or analytics where documents don’t need complex joins.

• Content-driven apps (CMS, catalogs) where items are self-contained.

MongoDB wasn’t a SQL killer. It was a shortcut for certain workloads that sometimes turned into technical debt.
Used with discipline, it’s still a solid choice. But if you treat “NoSQL” as “No Rules,” you’ll end up with a data swamp.

The NoSQL revolution didn’t kill SQL it just made Postgres even stronger.