The Database That Wasn't Supposed to Win: How PostgreSQL Outlived Oracle, MySQL, and MongoDB by Refusing to Compromise

It was 1996. Michael Stonebraker, the legendary Berkeley professor who'd already built one revolutionary database system (Ingres), stood in front of a room of graduate students and made an announcement that would echo through computing history.

"We're going to build a database," he said, "that does everything right."

Not everything fast. Not everything simple. Everything right.

In the corner, a quiet graduate student named Bruce Momjian took notes. He had no idea he'd just witnessed the birth of the database that would, decades later, power Uber, Instagram, Netflix, and Apple — while Oracle charged millions, MySQL cut corners, and MongoDB raised billions promising to disrupt everything.

This is the story of PostgreSQL: the database that refused to die, refused to compromise, and somehow beat everyone by simply being correct.

The Impossible Database That Shouldn't Exist

Most databases in the 1990s made a choice: be fast or be correct. Oracle chose correct and charged you $50,000 per CPU. MySQL chose fast and occasionally lost your data during crashes. SQL Server chose Windows and vendor lock-in.

PostgreSQL chose a third path: be academically rigorous, technically correct, completely free, and community-governed.

Wall Street laughed. Who would trust their business to a database with no company behind it? Who would pay for support when there's no 1-800 number?

But Stonebraker and his team weren't building for Wall Street. They were building for correctness.

The project started as POSTGRES (POST-inGRES, the successor to Ingres) in 1986. For ten years, it existed purely in academia — a research database that implemented every crazy idea computer science had about data: complex types, object-relational mapping, user-defined functions, transactional DDL.

Then in 1996, two graduate students — Marc Fournier and Bruce Momjian — did something that changed everything: they took the academic POSTGRES, replaced its query language with SQL, and released it to the world as PostgreSQL 6.0.

No company. No funding. No business model.

Just a mailing list and a commitment to correctness.

The Feature Nobody Else Wanted to Build

Here's where PostgreSQL's philosophy gets interesting.

In 1998, while MySQL was racing to be the fastest database on the planet, PostgreSQL was implementing something nobody asked for: Multi-Version Concurrency Control (MVCC).

MVCC is the technical term for "readers never block writers, and writers never block readers." It's the database equivalent of time travel — every transaction sees its own consistent snapshot of the database, frozen at the moment the transaction started.

The code to make this work is brutal. You're keeping multiple versions of every row. You're tracking which transactions can see which versions. You're running a background vacuum process to clean up old versions.

Oracle had MVCC. It was one of their crown jewels.

MySQL didn't. "Too slow," they said. "Too complex."

PostgreSQL implemented it anyway. Not because users were demanding it. Because it was the correct way to handle concurrency.

A decade later, when web applications started scaling to millions of concurrent users, MVCC became the difference between a database that worked and a database that fell over.

MySQL eventually added MVCC. In 2001. Five years later. By then, PostgreSQL had moved on to the next "impossible" feature.

The Turning Point: When Heroku Bet Everything on Postgres

For years, PostgreSQL existed in the shadows. Oracle owned the enterprise. MySQL owned the web. Microsoft owned Windows.

PostgreSQL was the database nerds used when they wanted to feel smart.

Then in 2010, a tiny startup called Heroku made a decision that changed everything.

James Lindenbaum, Heroku's co-founder, was building a platform-as-a-service for Ruby developers. He needed a database. The obvious choice was MySQL — it's what everyone used.

But Heroku's engineers kept hitting MySQL's limitations. No full-text search. No JSON. No window functions. No transactional DDL (you couldn't even add a column inside a transaction safely).

Meanwhile, PostgreSQL had all of it. And something else: the community would actually talk to them.

"With MySQL," one Heroku engineer later wrote, "you filed a bug and hoped Oracle would fix it in three years. With Postgres, you emailed the mailing list and got a response from core contributors in three hours."

Heroku bet their entire database-as-a-service offering on PostgreSQL.

The startup community watched. If Heroku was using it, maybe it wasn't just for academics.

Instagram launched in 2010. PostgreSQL. Disqus handled billions of comments. PostgreSQL. Reddit rewrote their backend. PostgreSQL.

By 2015, the pattern was clear: the most sophisticated engineering teams were all migrating to PostgreSQL, not from it.

The JSON War: When MongoDB Came for Postgres' Lunch

Then MongoDB showed up with $1.6 billion in funding and a simple pitch: "Relational databases are dead. The future is JSON."

Their marketing was brilliant. Their conferences were packed. Their logo was everywhere.

Developers started asking: should we abandon PostgreSQL for MongoDB?

The PostgreSQL core team's response was quintessentially Postgres: they read the MongoDB marketing materials, read the technical papers, and in 2012 added native JSON support to PostgreSQL.

Not half-baked JSON. Full JSON with indexing, querying, and ACID guarantees.

Two years later, they added JSONB — a binary JSON format that was faster than MongoDB for most queries.

Then they added GIN indexes for JSON. And JSON path queries. And JSON aggregation functions.

By 2016, you could use PostgreSQL as a document database that was faster, more reliable, and more feature-complete than MongoDB — while also being a world-class relational database.

Instagram processed 25 billion likes per day. All in PostgreSQL with JSON columns.

MongoDB's pitch started to crack. Why would you use a database that only does documents when you could use one that does documents and relations and time-series and full-text search?

The Architecture That Makes It All Possible

What makes PostgreSQL different isn't any single feature. It's the architecture.

Most databases are monolithic. The query planner, storage engine, and type system are all tangled together. Want to add a new data type? Recompile the database.

PostgreSQL is built like Unix: small, composable pieces.

The core database is just a framework. Everything else — even basic types like integers and strings — is implemented as extensions that plug into that framework.

Want full-text search? Enable the pg_trgm extension. Want geospatial queries? Add PostGIS. Want time-series data? Install TimescaleDB. Want vector similarity search for AI embeddings? Add pgvector.

Each extension gets the full power of the database: custom types, custom indexes, custom operators, custom aggregates.

This is why PostgreSQL keeps winning. When a new technology trend emerges — machine learning, cryptocurrencies, real-time analytics — someone just writes a PostgreSQL extension.

Oracle can't do this. MySQL can't do this. MongoDB definitely can't do this.

The architecture that seemed over-engineered in 1996 became PostgreSQL's superpower in 2024.

The Numbers That Prove It Won

By 2024, the evidence was overwhelming:

• DB-Engines Ranking: PostgreSQL is the 4th most popular database globally, and the #1 fastest-growing for seven consecutive years
• Stack Overflow Survey: PostgreSQL is the most loved database, beating even Redis
• AWS Revenue: Amazon's managed PostgreSQL service (RDS for PostgreSQL + Aurora PostgreSQL) generates more revenue than their managed MySQL
• GitHub Stars: The PostgreSQL GitHub mirror has 15,000+ stars; the ecosystem has hundreds of extensions with millions of downloads

But the real proof is simpler: name a successful tech company launched after 2010.

Chances are, they're running PostgreSQL.

Uber's entire routing and dispatch system? PostgreSQL with PostGIS. Instagram's 2 billion users? PostgreSQL, scaled to 1 petabyte across thousands of servers. Spotify's recommendation engine? PostgreSQL. Apple's iCloud? PostgreSQL.

The database that "wasn't supposed to win" beat Oracle without charging a cent, beat MySQL without compromising correctness, and beat MongoDB without abandoning relational algebra.

The Legacy: Correctness Compounds

In 2019, Michael Stonebraker won the Turing Award — computer science's Nobel Prize — largely for his work on database systems, including PostgreSQL.

In his acceptance speech, he said something that explains why PostgreSQL won:

"Most systems are built for the problems of today. We built for the problems we didn't know we'd have tomorrow."

That's the PostgreSQL philosophy in one sentence.

MVCC seemed overkill in 1998. It became essential in 2008 when web apps needed millions of concurrent users.

Extensible architecture seemed academic in 1996. It became critical in 2023 when everyone needed vector search for AI.

Transactional DDL seemed paranoid in 2000. It became vital in 2020 when deployments needed to be atomic and rollback-safe.

Every "unnecessary" feature PostgreSQL built became necessary five years later.

Meanwhile, MySQL spent years backfilling MVCC. Oracle spent years trying to match PostgreSQL's JSON performance. MongoDB spent years adding transactions (and still doesn't have them right).

PostgreSQL didn't win by being first. It won by being correct.

Today, when a startup asks "which database should we use?", the default answer isn't Oracle or MySQL or MongoDB.

It's PostgreSQL.

Not because it's perfect. Not because it's the fastest. Not because it has the best marketing.

Because thirty years ago, a professor and a room full of graduate students decided to build a database that did everything right — even if nobody wanted it yet.

And they were patient enough to wait for the world to catch up.