The Elephant in the Room: Why the World Chose Postgres

The Question You Never Asked

This is episode one of The Vibecoder's Guide to Postgres.

Here is something that happens thousands of times a day, all over the world. A developer opens their AI coding assistant, types something like "set up a database for my app," and the AI responds with a PostgreSQL configuration. Not MySQL. Not MongoDB. Not SQLite. PostgreSQL. Every time, as if the question was never really a question at all.

If you have been building things with AI assistance, with Cursor or Claude Code or Copilot writing most of your code, you have probably noticed this. The AI just picks Postgres. It sets up the connection string, writes the schema, generates the migrations, and moves on. You never stopped to ask why, because the AI seemed so confident about the choice that questioning it felt unnecessary.

But here is the thing. That confidence did not come from nowhere. It came from a fifty-year story that starts in a university office in Berkeley, California, with a young professor who had just finished a PhD thesis he considered completely useless, and who decided, on more or less a whim, to try building a database.

His name is Michael Stonebraker. And the database he built, through a series of accidents, arguments, and one spectacularly well-timed act of serendipity, became the foundation of almost everything your AI is recommending to you today. This is the story of how PostgreSQL became the elephant in the room, the database so dominant that nobody even bothers to debate the alternatives anymore.

The Professor Who Got Bored

Michael Stonebraker arrived at the University of California, Berkeley in nineteen seventy-one as a freshly minted assistant professor. He was born in Newburyport, Massachusetts, got his bachelor's from Princeton, and had just completed a PhD at the University of Michigan on an aspect of Markov chains. Years later, he would describe that thesis with characteristic bluntness.

[laugh] My PhD thesis was on an aspect of Markov chains, and that, I realized, had no practical value whatsoever.

So he needed a new direction. Around the same time, a British mathematician working at IBM named Edgar Codd had published a paper that would reshape the entire computing industry. It was called "A Relational Model of Data for Large Shared Data Banks," and it proposed something radical for nineteen seventy: instead of storing data in rigid hierarchical trees, you could store it in simple tables of rows and columns, and use mathematical logic to query it. The idea was elegant, almost obvious in hindsight. [serious] IBM, which was making good money selling its existing hierarchical database, declined to build it.

Stonebraker read Codd's papers. He talked to his colleague Eugene Wong. And then, in nineteen seventy-three, with what he would later describe as no experience whatsoever, they started building one of the first relational database systems in the world.

[laugh] Based on no experience, we set out to build Ingres. And that was what got me my tenure.

INGRES, which stood for Interactive Graphics and Retrieval System, was a prototype by nineteen seventy-four. It ran on Unix, which meant it could run on relatively affordable minicomputers instead of requiring the mainframes that IBM's System R needed. Stonebraker shipped it to other universities, where students used it, modified it, and spread it further. It was one of only two working relational database systems in the entire world during the nineteen seventies, and it proved that Codd's theoretical model could actually work in practice.

In nineteen eighty, Stonebraker and Wong founded a company called Relational Technology to commercialize INGRES. The company would later rename itself Ingres Corporation. It did well. But Stonebraker was already thinking about what came next, because he had been talking to customers, and they kept telling him the same thing.

The relational model was not enough.

Post-Ingres

The problem was that real-world data did not fit neatly into rows and columns. Customers wanted to store geographic coordinates, time series, complex documents, custom data types that the database had never heard of. One customer called Stonebraker and told him, bluntly, that he had implemented time all wrong. The relational model as Codd defined it only knew about a handful of basic types: numbers, strings, dates. Everything else had to be awkwardly forced into those boxes.

So in nineteen eighty-six, Stonebraker and his colleague Larry Rowe published a twenty-eight-page paper announcing the design of a new system. They called it POSTGRES. The name was a pun, a play on "post-Ingres," meaning the thing that comes after INGRES. The core idea was extensibility. Users should be able to define their own data types, their own operators, their own ways of indexing and querying data. The database should not dictate what kinds of information it could hold. It should adapt to whatever the user needed.

This was nineteen eighty-six. The internet barely existed. Object-oriented programming was still exotic. And here was Stonebraker, building a database that could store and query literally anything, because he figured that whatever people needed next, the database should be ready for it.

The project was funded by DARPA, the Army Research Office, and the National Science Foundation. By nineteen eighty-seven, a prototype was running. By nineteen eighty-nine, version one shipped to external users. Through the early nineties, the project kept evolving, adding multiple storage managers, improving the query executor, rewriting the rule system. But it used a query language called QUEL, which was Stonebraker's own design from the INGRES days. Not SQL. This would turn out to matter enormously.

In nineteen ninety-three, with version four point two, the Berkeley POSTGRES project officially ended. Stonebraker moved on to other ventures. The code sat there, open and available, a research prototype that worked but that nobody was particularly stewarding. It could have died right there. Most academic software does.

[slow] It did not die. And the reason it did not die is one of the best accidents in the history of software.

Grumpy and Sleepy

In nineteen ninety-four, two Berkeley graduate students named Andrew Yu and Jolly Chen did something that changed everything. They took the POSTGRES source code and replaced its QUEL query language with SQL. SQL had won the database language wars. It was the standard that IBM's System R had pioneered, that Oracle had copied, that every commercial database in the world now spoke. QUEL was technically elegant, but SQL was the language the world had chosen.

Yu and Chen called their modified version Postgres95. They rewrote it entirely in ANSI C, shrunk the code by twenty-five percent, and improved performance by thirty to fifty percent over the original Berkeley version. They added a new interactive SQL tool called psql. They made it, for the first time, something that a working developer could realistically use.

Stonebraker would later talk about Yu and Chen in his Turing Award lecture, with a mix of affection and amazement at what their work had set in motion.

[happy] Serendipity played a huge role. The biggest impact of Postgres by far came from two Berkeley students that I'll affectionately call Grumpy and Sleepy. They converted the academic Postgres prototype from QUEL to SQL in nineteen ninety-five.

In nineteen ninety-six, the project was renamed one final time. Postgres95 became PostgreSQL, to reflect its SQL support while honoring the original Berkeley heritage. The version number was set to six point zero, continuing the sequence from the Berkeley project. And then something happened that no one had planned.

A pick-up team of volunteers, people who had no connection to Stonebraker or Berkeley, started maintaining and improving the code. They fixed bugs. They added features. They made it reliable enough for production use. This was open source at its most organic, not a corporate project with a roadmap, but a loose community of people who saw something valuable and decided to take care of it.

A pick-up team of volunteers, none of whom have anything to do with me or Berkeley, have been shepherding that open source system ever since. We all owe a huge debt of gratitude to them, because they have robustized that code line and made it so it really works.

[calm] Stonebraker has a word for all of this. He calls it a wonderful accident. The database he built as a research project at Berkeley, the one that almost disappeared when the funding ended, had been picked up by strangers and turned into something real. He had nothing to do with it. He finds this delightful.

The Name Nobody Can Agree On

Before we go further, we need to talk about the name, because it is a source of mild but persistent chaos.

The official name is PostgreSQL. Capital P, lowercase ostgre, capital SQL. It is pronounced post-gres-Q-L. Four syllables, then two letters. Almost nobody says this. In practice, the entire world just says Postgres. Two syllables. Done. The PostgreSQL community reviewed the naming question in two thousand and seven and decided to keep PostgreSQL as the official name while formally accepting Postgres as an alias.

If you are wondering about the elephant, that comes from a mailing list post in nineteen ninety-seven by a community member named David Yang, who suggested that the project adopt an elephant as its mascot.

If you want an animal-based logo, how about some sort of elephant? After all, as the Agatha Christie title read, elephants can remember.

Not everyone was convinced.

[worried] Elephant will give people the wrong idea. They'll think Postgres is a large, slow, bulky database.

The elephant won anyway. Its name is Slonik, derived from the Russian word for little elephant. That name, incidentally, is why the Slony replication system is called Slony, which is Russian for elephants. The current blue elephant logo debuted in two thousand and three and has been the face of the project ever since.

For this series, we will mostly just say Postgres. Life is too short for five syllables.

The Long Shadow of the Dolphin

If Postgres was so good, why did MySQL dominate the web for fifteen years?

The answer is timing, simplicity, and a fish. Well, a dolphin. MySQL arrived in nineteen ninety-five with a different philosophy. Where Postgres was the careful academic project that prioritized correctness, extensibility, and standards compliance, MySQL was the fast, easy, good-enough option. It was the default database of the LAMP stack, Linux, Apache, MySQL, PHP, the combination that powered the first generation of the web. WordPress ran on MySQL. Drupal ran on MySQL. If you were building a website in two thousand and five, you used MySQL because that was what the tutorials told you to do.

Postgres, during this same period, was the database your computer science professor recommended. It was technically superior in almost every measurable way. It had better transaction handling, proper multiversion concurrency control, a richer type system, better standards compliance. But it was harder to set up, had less documentation aimed at beginners, and did not have a catchy stack acronym.

[serious] Then, in two thousand and eight, something happened that changed the calculus for every MySQL user on earth. Sun Microsystems bought MySQL AB, the company behind MySQL. And then, in January two thousand and ten, Oracle, the largest proprietary database company in the world and MySQL's biggest competitor, bought Sun. Suddenly, the database that half the internet ran on was owned by the company that had the strongest incentive to make it worse.

The MySQL co-founder, Michael Widenius, saw the writing on the wall. On the day of the Oracle announcement, he forked MySQL into a new project called MariaDB. But the damage to trust was already done. Developers started looking for alternatives, and when they looked, they found Postgres sitting there, technically superior and owned by nobody. No corporation. No shareholders. Just volunteers.

Stonebraker, characteristically, calls this another happy accident.

The migration accelerated through the twenty-tens. Instagram built one of the largest PostgreSQL deployments in the world, serving billions of daily interactions. Spotify chose Postgres for user data, playlists, and recommendations. Reddit runs its core data model on Postgres, storing every link, comment, account, and subreddit. Apple quietly replaced MySQL with Postgres as the default database on macOS Server starting with OS X Lion in two thousand and ten.

By twenty twenty-three, the Stack Overflow developer survey showed PostgreSQL as the most popular database among developers for the first time. By twenty twenty-five, fifty-five point six percent of professional developers were using it, the largest single-year jump in the survey's history. Four consecutive years as the most admired, most wanted, and most used database. The debate was over.

Rabbit Hole: Why Postgres Actually Won

This next section goes into the technical reasons Postgres beat its competitors. If you just want to know why your AI picks Postgres and when you might want something else, skip ahead to the next chapter. But if you are curious about what makes this database different under the hood, here is the short version.

Three things separate Postgres from the rest.

First, MVCC, which stands for multiversion concurrency control. When two people try to use a traditional database at the same time, one of them has to wait. Readers block writers. Writers block readers. Postgres solved this in the nineteen eighties by keeping multiple versions of each row. When you read data, you see a consistent snapshot from the moment your transaction started. When someone else writes data at the same time, they create a new version of the row instead of overwriting yours. Readers never block writers. Writers never block readers. This sounds like a small thing until you have a hundred users hitting your database simultaneously, and then it is everything.

Second, extensibility, the thing Stonebraker designed the whole system around. Postgres lets you define custom data types, custom operators, custom index types, and custom functions in multiple programming languages. This is not a bolt-on feature. It is the architecture. And it is why Postgres keeps absorbing the jobs of specialized databases. Need geographic queries? There is PostGIS. Need vector search for AI embeddings? There is pgvector. Need time-series data? There is TimescaleDB. Need full-text search? It is built in. Every time a new category of database appears, someone builds a Postgres extension that does the same thing, and then people stop needing the specialized database.

Third, standards compliance. Postgres follows the SQL standard more closely than any other major database. This means that the SQL you learn for Postgres works almost everywhere else, and the SQL that AI models generate, trained on decades of standards-compliant examples, works correctly in Postgres more often than in any alternative. This is a bigger deal than it sounds in the age of AI-generated code.

There is a trade-off. The same MVCC system that gives Postgres its concurrency advantage also creates dead rows that need to be cleaned up by a process called VACUUM. This was a real problem in the early days. Uber famously switched from Postgres to MySQL in two thousand and sixteen, partly because of write amplification caused by this mechanism at their extreme scale. The blog post they published about it generated one of the most heated database debates in internet history. But for the vast majority of applications, including ones far larger than most vibecoders will ever build, Postgres handles this just fine.

The Boring Technology Advantage

In twenty fifteen, an engineer named Dan McKinley, who was working at Etsy, published a blog post called "Choose Boring Technology." It became one of the most influential essays in the software industry, and its argument applies perfectly to why Postgres keeps winning.

Every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while.

McKinley's point was this. Every new technology you adopt comes with costs you cannot see yet. You have to learn its failure modes. You have to figure out monitoring, backups, and debugging. You have to train your team. You have to discover the edge cases the hard way. With boring technology, all of that work has already been done by thousands of people before you. The failure modes are documented. The Stack Overflow answers exist. The AI training data includes millions of examples.

The capabilities of boring technology are well understood. But more importantly, their failure modes are well understood.

McKinley explicitly listed Postgres as an example of boring technology, alongside MySQL, PHP, and Python. In his framework, boring is the highest compliment. It means reliable, predictable, and thoroughly understood.

This is where the vibe coding angle gets interesting. When an AI writes your database code, it is essentially making the "choose boring technology" argument for you, automatically. The AI suggests Postgres because its training data contains more working Postgres examples, more answered Stack Overflow questions, more documented patterns than any other database. The AI is not making a principled architectural decision. It is following the path of least resistance, and that path leads to Postgres because Postgres has the deepest, widest body of working examples on the internet.

The result, entirely by accident, is that vibecoders end up making the right choice for the right reasons without knowing the reasons. You get a database with decades of battle-tested reliability, a massive extension ecosystem, and a community that has solved almost every problem you will encounter, all because the AI picked the most boring option.

When Postgres Is Overkill

Here is the part where we push back against the default, because sometimes Postgres really is more than you need.

If you are building a single-user application, a desktop tool, a mobile app, a personal project that will never serve more than one person at a time, SQLite is probably the better choice. SQLite is not a server. It is a library that reads and writes a single file on disk. No installation, no configuration, no process to manage. You just point your app at a file and start querying. It is the most deployed database engine in the world, running on every iPhone, every Android device, every web browser.

The moment you need concurrent access from multiple users, or you need extensions like pgvector for AI embeddings, or you need your database to run as a service separate from your application, that is when Postgres earns its complexity. For most web applications, most APIs, most anything that involves more than one person using the thing, Postgres is the right choice. But for a prototype, a command-line tool, a personal project, do not let the AI talk you into running a Postgres server when a SQLite file would do.

The rule of thumb is this. If your application lives on a server and serves multiple users, use Postgres. If your application lives on a single device or you are just exploring an idea, use SQLite. If your AI suggests MongoDB, ask it why, and listen carefully to the answer, because there usually is not one.

One Person, Eight Databases, One Server

Let me make this concrete with a real example, the kind of setup that is increasingly common in the vibe coding world.

There is a developer who runs a single VPS, a virtual private server, at a hosting company called Scaleway. The server runs PostgreSQL sixteen on Ubuntu. On that one Postgres instance, there are eight databases. One powers a live news site that handles breaking stories and real-time updates. Another runs a music service. A third manages a full productivity suite with task management, calendars, and a knowledge base. There is an e-commerce platform, a photography gallery, a newsletter system, and an institutional memory archive that uses pgvector to store AI embeddings for semantic search across thousands of documents.

One person. One server. Eight databases covering every category of application you can think of. All running on Postgres, all managed with AI assistance writing the schemas, the queries, the migrations, and the backup scripts. Daily backups go to S3 storage automatically. Hourly backups protect the most critical services.

This is what vibe coding with Postgres actually looks like in production. Not a massive team of database administrators tuning query plans. Not a fleet of specialized databases for different workloads. Just one developer, one well-chosen database, and AI handling the repetitive parts. The server has been running for years. The backups have been tested. The database just works, because that is what Postgres does when you treat it with a minimum of respect.

And that is the point of this entire series. You do not need to become a database administrator. You do not need to understand every line of a query plan or memorize the PostgreSQL documentation. But you do need to understand enough to know when the AI is making a good choice and when it is leading you off a cliff. You need to know what questions to ask, what warning signs to watch for, and what Postgres can do that you might not even know to ask about.

What Comes Next

In twenty fourteen, Michael Stonebraker received the Turing Award, the highest honor in computer science. He was seventy-one years old and had been working on databases for over forty years. In his acceptance, he said something that captures the ethos of a lifetime building systems.

It is every computer scientist's dream to get this award, and I am so very honored to be selected.

[sad] He dedicated the lecture to his friend Jim Gray, a fellow database pioneer and Turing Award winner who vanished while sailing alone in San Francisco Bay in two thousand and seven. Stonebraker is eighty-two years old now and still working, still publishing, still starting companies. When asked about retirement, he says he cannot imagine playing golf three days a week.

The database he built at Berkeley as an experiment, the one he named as a pun, the one that two students saved by adding SQL, the one that a volunteer army turned into the most trusted database in the world, that database is running underneath your next project. Your AI already chose it for you.

Over the next eleven episodes, we are going to open it up and look inside. We will learn how tables work, how to write SQL, how to make queries fast, how to change a schema without breaking everything, and how to sleep soundly knowing your data is safe. We will build on the real-world foundation of a single developer running eight databases on one server, because that is a setup any vibecoder can relate to.

Next episode, we start at the very beginning: your first table. How to think about data in rows and columns, why AI-generated schemas are both impressively good and subtly terrible, and the constraints that keep your data from turning into chaos.

[slow] The elephant remembers everything. That is the whole point.