/
.webp)
Generated by Master Biographer | Source for LinkedIn Content
Berkeley, California. 1973.
There is a paper sitting on Michael Stonebraker's desk.
It was published three years earlier by an IBM researcher named Edgar Codd. Eleven pages. Dry title: A Relational Model of Data for Large Shared Data Banks. IBM had essentially ignored it — filed it away as theoretical mathematics with no commercial application. The mainframe business was booming. Why would you redesign the foundation?
But Stonebraker read it differently. He read it the way a structurally curious engineer reads a blueprint for something nobody has built yet. He called his colleague Eugene Wong into the office.
"I think this is right," he said. "And nobody has actually proven it works."
This is how the history of modern databases begins: not with a startup, not with venture capital, not with a product roadmap. It begins with two professors at a public university deciding to build a thing that the largest technology company in the world had theorized but not attempted to prove.
The project they launched that year was called INGRES.
What you need to understand — what makes the rest of this story coherent — is that INGRES worked. It worked so well that a decade later, the relational database was the unquestioned foundation of enterprise computing. Oracle. IBM DB2. Microsoft SQL Server. They all descended, intellectually and commercially, from the proof-of-concept Stonebraker built at Berkeley with graduate students and government grants.
And by 1985, Michael Stonebraker was standing inside his own cathedral, looking at the walls, and thinking: this was a mistake.
Not INGRES. What he'd done with INGRES was correct.
The mistake was the architecture. The design assumptions baked in before anyone understood what people would actually ask databases to do.
He stood at a whiteboard and wrote the question that would consume the next decade of his life:
What would I do differently if I could start over?
Twenty years after he answered that question, his answer — a research prototype abandoned by its university, rescued by two graduate students, renamed by a community that didn't yet know what it had, and carried to production by volunteers scattered across the early internet — would power Instagram, Spotify, Reddit, and half the web applications on the planet.
Nobody planned this. Nobody funded it. Nobody managed it.
It happened because the architecture was right, and because the right architecture, given enough time and enough stubborn people, eventually wins.
Before POSTGRES, there was INGRES. Before INGRES, there was a race.
In 1970, Edgar Codd's paper proposed that data should be stored in relations — tables with rows and columns — and manipulated through relational algebra. It was mathematically elegant. It was also completely abstract. Nobody had built it yet.
In the early 1970s, two groups decided to build it at the same time.
IBM Research, in San Jose, started building System R. They had money, engineers, and institutional credibility. They were the largest computer company in the world.
At Berkeley, Stonebraker and Wong started building INGRES. They had government grants, rotating teams of graduate students, and a culture — Berkeley in the 1970s — that valued proving things through working code rather than internal memos.
Both groups were small. Both groups were obsessive. And according to Stonebraker, they were intensely aware of each other, reading each other's papers, racing to solve the same problems.
By the mid-1970s, they had both produced working relational database systems. The first two full-function, working relational databases in history.
What happened next shaped everything downstream.
IBM's System R became IBM DB2, released commercially in 1983. It was brilliant and expensive and corporate and eventually moved too slowly for its own good.
INGRES, because it was a university project built with public funding, was distributed freely — the source code mailed on magnetic tapes to anyone who asked. Hundreds of universities and research labs started running it. Graduate students all over the world cut their teeth on it. By the late 1970s, Stonebraker had inadvertently created the first major open-source-adjacent database ecosystem, before the phrase "open source" existed.
In 1980, Stonebraker co-founded Relational Technology Inc. to commercialize INGRES. The company went public in 1988. A decade after two professors decided to prove Codd right, they had turned an academic idea into a public company.
This is the context you need for what happened next: Stonebraker already had a successful commercial product. He didn't have to start over. He chose to.
The story Stonebraker tells most often is about a phone call.
A customer called him and said: "You implemented time all wrong."
The customer needed to model financial years as 360-day periods. Banking conventions. Legitimate use case. INGRES — like every relational database of the era — had a fixed built-in data type for dates and times. It was either correct, in the standard Gregorian sense, or it was wrong for your use case. There was no third option. You couldn't change it.
Stonebraker said he could fix the specific bug. But the underlying problem was architectural. INGRES had been built assuming that the set of data types a database needed was known in advance. Integers. Floats. Strings. Dates. A fixed roster. Whatever fell outside that roster was your problem.
This drove him insane.
Not because it was an unusual complaint. Because it was a systematic complaint. He started counting how many times users ran into the same category of wall: "We need a data type your database doesn't support." Geographic coordinates. Time-series data. Geometric objects. Astronomical measurements. Medical imaging metadata.
Every major scientific computing project had exotic data. Every specialized industry had edge cases. And INGRES, like every relational database, told them all the same thing: no.
Then there was the second category of complaint, which was worse: researchers building expert systems on top of databases. Artificial intelligence work in the 1980s was consumed with knowledge bases — systems that could reason over structured data. But relational databases weren't built for inferencing. They could store the facts but not reason about them.
Researchers were rebuilding database infrastructure from scratch because existing databases couldn't support their work. Reinventing the wheel. Intellectual waste on a massive scale.
Stonebraker sat with these complaints for a year.
Then he made a decision that felt, at the time, like either vision or hubris: he would build a new system from the ground up, where extensibility was the first principle — not the feature list. The system would be a platform. Users would define their own data types, their own operators, their own indexing methods, their own functions. The query processor would adapt.
He called it POSTGRES. Post-INGRES. What came after.
To understand what POSTGRES became, you have to understand what it meant to do research at Berkeley in the 1980s.
Berkeley's computer science department in this era was not like an engineering consultancy. It was not trying to ship products. It was trying to figure out what was true. The funding came from DARPA, the Army Research Office, and the NSF — government agencies that wanted to know what the future of computing looked like, not agencies that needed the answer by Q4.
This created a specific kind of culture. You could spend months on something that might not work. You were encouraged to be wrong in interesting ways. The measure of success was not whether something shipped — it was whether you learned something.
Stonebraker published the design paper for POSTGRES in 1986, at the ACM SIGMOD Conference on Management of Data. Co-authored with Lawrence A. Rowe. It laid out the core ideas: user-defined data types. User-defined functions. Rules. Table inheritance. A storage system designed to support time travel — the ability to query the database as it existed at any point in the past.
DARPA funded it. The Army Research Office funded it. ESL, Inc. funded it. The National Science Foundation funded it. By the standards of academic research in the 1980s, it was well-resourced.
Then Stonebraker started recruiting students.
The POSTGRES project ran for eight years at Berkeley. During that time, it functioned as something between a research lab and a trade school. Graduate students cycled through, spent a year or two on the project, graduated, went to work at Oracle or IBM or Sybase, and were replaced by new students.
Stonebraker's management style, as described by people who worked with him, was not gentle.
He would arrive in the morning having read a paper on the train, walk into your office with the paper, point at a specific figure, and say: "We should implement this. How long will it take?"
You would say: six months.
He would say: "You have three weeks."
Then he'd leave.
The students built:
User-defined data types with custom operators. You could define a new data type called "polygon" and then define a new operator called "contains" and write a SQL query asking which polygons contained a given point. The query processor would use your operator as naturally as if it had been built in since the beginning. This was the thing that would, two decades later, make PostGIS possible, make pgvector possible, make the entire extension ecosystem possible.
User-defined functions. Write a function in C. Load it into the database. Call it from a query. The database would execute your code as part of query processing.
Table inheritance. A "vehicles" table with columns that a "cars" table and a "trucks" table could inherit, with their own additional columns. Queries against "vehicles" would automatically include data from both.
Rules and triggers. Automatic actions in response to database events. If a row is inserted that violates a business rule, fire a rule.
Time travel. The ability to query: "what did this table look like at 3pm yesterday?" The system preserved historical state. You could audit not just the current data but the complete history of how it arrived at the current state.
Version 1 shipped in June 1989. It was rough. The documentation was sparse. Performance was not competitive with production databases. But the extensibility features worked. You could define a new data type and query it. This had never been done before in a production-grade system.
Version 2 shipped in June 1990 with a redesigned rule system. Version 3 in 1991 added multiple storage managers and rewrote the rule system again. By 1992, POSTGRES had become the primary data manager for Sequoia 2000, a major scientific computing project studying global climate change.
Jet engine performance monitoring. Asteroid tracking databases. Medical information systems. Geographic information systems. The places that needed exotic data types were using POSTGRES. The extensibility thesis was being validated in the real world.
By 1993, the external user community for POSTGRES had nearly doubled in size.
This was not good news for the Berkeley lab.
The project was always research infrastructure, funded to answer intellectual questions. But as the user community grew, those users brought bugs. And bug reports. And feature requests. And documentation requests. And the specific, grinding, time-consuming work of responding to people who had production systems running on your software and needed answers now.
The Berkeley lab was not funded to do user support. The graduate students were not paid to answer mailing list questions from database administrators at aerospace companies. Their dissertations were not on the topic of fixing edge cases in PostQUEL.
By 1994, the project was drowning. The official language from the documentation was diplomatic: "it was becoming increasingly obvious that maintenance of the prototype code and support was taking up large amounts of time that should have been devoted to database research."
The undiplomatic version: the success of the project was destroying the lab's ability to do its actual job.
In 1994, POSTGRES Version 4.2 shipped. The Berkeley project officially declared it the final release and shut down the active development effort.
Stonebraker moved on. He'd already been building Illustra Information Technologies — a company commercializing POSTGRES's extensibility ideas for the enterprise market. The research had done its job. The prototype had proven the concepts. Time to let the academic work rest and turn the ideas into a business.
The source code sat on the Berkeley servers. Powerful. Architecturally ahead of anything else available. And — fatally, for its immediate usefulness — written around PostQUEL, a query language that, by 1994, had no future at all.
SQL had won.
Oracle ran SQL. IBM ran SQL. Microsoft ran SQL. Every developer in the world who was learning databases was learning SQL. PostQUEL was more expressive in certain ways, more powerful for certain kinds of queries. It didn't matter. The network effects of SQL were decisive. A database that didn't speak SQL was a museum piece.
The most advanced open-source database system ever built was, for practical purposes, dead.
Andrew Yu and Jolly Chen were graduate students at Berkeley. They had been using POSTGRES. They understood its architecture. They understood exactly what it could do and exactly why its query language made it functionally unusable for the world outside the research lab.
And they had a simple idea that was, in practice, extraordinarily difficult: replace PostQUEL with SQL.
Simple in concept. Catastrophic in implementation.
PostQUEL and SQL are not just different syntaxes over the same engine. They reflect different design philosophies. Replacing the query language meant reaching into the deepest layers of the system — the parser, the query optimizer, the execution engine — and rewriting core components while keeping the extensibility architecture intact.
They started in 1994. Working nights. Working weekends. This was not funded research. This was not their dissertation work. This was two people who believed that the system needed to exist and were willing to do the work required to make it exist.
When they finished:
- The codebase was 25% smaller than POSTGRES 4.2
- The system was 30-50% faster on the Wisconsin Benchmark
- It was rewritten entirely in ANSI C
- It spoke SQL
They called it Postgres95 and released it as open source in May 1995.
The announcement was quiet. There was no press release. No launch event. There was a post to an internet mailing list. Yu and Chen put the code on an FTP server and told people it was there.
What happened next surprised everyone, including them.
By 1995, the early web was real. Not yet the commercial web — that would come after Netscape — but the academic and technical web. Mailing lists and FTP servers and Usenet newsgroups and a culture of sharing and building that had been there since the ARPANET.
People who had been frustrated by POSTGRES's PostQUEL constraint started showing up. Database researchers. System administrators. Graduate students from other universities. Web developers building the first generation of database-backed websites.
And something unusual happened: they started fixing bugs.
Not just reporting bugs. Fixing them. Downloading the code, understanding the problem, writing the fix, posting the patch to the mailing list.
Marc Fournier, a Canadian developer, set up the first public mailing list infrastructure for Postgres95. He gave the project organizational scaffolding it hadn't had before.
Bruce Momjian, then a database administrator who had been working with Postgres95 and growing frustrated with specific limitations, started contributing patches. He had never worked on database internals before. He learned by doing.
Vadim Mikheev, a Russian developer, became one of the most significant technical contributors — his work on stabilizing the code inherited from Berkeley, including foundational work on the concurrency control mechanisms, was essential to making Postgres production-ready.
These were not employees. They were not paid. They were people who needed the software to exist, who had the skills to make it better, and who were operating in a culture — internet technical culture in 1995 — that said: if the thing you need doesn't exist well enough, you should make it exist.
By 1996, the name "Postgres95" was already obviously wrong. It implied a temporary fork. It implied a year. It implied someone's side project.
This was not a side project anymore.
The community chose a new name: PostgreSQL. Post-INGRES, plus SQL. The name acknowledged both the lineage from Stonebraker's work and the essential modification that had made it useful. It was pronounced "Post-gres-Q-L," sometimes shortened to just "Postgres" in casual conversation, because nobody wanted to say "Post-gres-Q-L" every time.
PostgreSQL.org launched on October 22, 1996.
On January 29, 1997, the first official PostgreSQL release shipped as Version 6.0 — continuing the version sequence from Berkeley's original project, honoring the lineage rather than pretending to be something new.
The PostgreSQL Global Development Group formed. No corporate parent. No venture backing. No headquarters. A distributed, volunteer organization with a public mailing list as its governance structure.
Also in 1997, the community was arguing about a mascot.
On April 3rd, a community member named David Yang posted to the mailing list. He had been thinking about what kind of symbol fit a database — something that stored information reliably and for a long time.
"But if you want an animal-based logo," he wrote, "how about some sort of elephant? After all, as the Agatha Christie title reads, elephants can remember..."
Not everyone agreed. One response warned that elephants suggested something "large, slow, bulky." A counterargument came back: elephants were "big, strong, reliable, and never forget."
The debate ran for months. Eventually the community went with the elephant. It became official in October 1999, a stylized elephant inside a diamond shape.
In 2003, when PostgreSQL Inc. was formed as a commercial support entity, they hired a designer to create a proper professional version. The diamond was removed. The elephant became the clean blue icon still used today.
Its name — a fact most PostgreSQL users don't know — is Slonik. Russian for "little elephant." The name was given when Jan Wieck, a developer building a replication system called Slony-I, saw the logo file named slonik.gif and asked what it meant. "Little elephant." He named his entire replication system around the same vocabulary: individual nodes run "slon" (elephant), clusters are "Slony," and the configuration tool is "slonik."
A database mascot named in Russian. Because in 1997, the internet had no geography, and the best contributor to your open-source project might be writing code from Novosibirsk.
PostgreSQL in 1997 was architecturally extraordinary and operationally terrifying.
It had bugs. Not obvious bugs — obscure, edge-case, data-corrupting bugs that would not appear in normal use but would appear when your database hit a certain scale under a specific load pattern on a Tuesday. The kind of bugs that are only discovered when someone's production system fails.
The community spent the late 1990s in what was essentially a long reliability crucible. Every production deployment was a test. Every bug report was forensic evidence. The mailing lists were dense with patch discussions, performance analyses, and detailed post-mortems from users who had found a new way to break the system.
This was not glamorous work. It was unglamorous, meticulous, technically demanding, and done entirely by volunteers.
But it was the work that had to be done.
PostgreSQL 7.1 in 2001 achieved full ACID compliance and introduced Write-Ahead Logging (WAL) — a fundamental mechanism that ensures data integrity by recording changes to a log before applying them to the database. With WAL, you could crash a PostgreSQL server mid-transaction and know that when it came back up, the data would be consistent. This sounds basic. In a production database, it is everything.
This was the moment PostgreSQL became legitimate. Not just "pretty good for open source." Legitimate — comparable to Oracle, IBM DB2, and Microsoft SQL Server on the core correctness guarantees that enterprises actually required.
In 2001, a project called PostGIS launched. It added full geographic object support to PostgreSQL — geometry types, spatial operators, geographic indexing, the ability to ask a database which of 50,000 store locations was closest to a customer's address.
The critical detail, the one that validated everything Stonebraker had argued in 1986: PostGIS was built entirely as a PostgreSQL extension. Zero modifications to PostgreSQL's core code.
The PostGIS developers created:
- New data types (geometry, geography, raster)
- New operators (distance, intersection, containment)
- New indexing methods (R-trees for spatial queries)
And PostgreSQL's extension infrastructure handled all of it. The query optimizer understood how to use the new types. The storage manager could index them. The planner could make intelligent decisions about spatial queries.
This was extensibility as first principle paying its dividend, fifteen years after Stonebraker wrote the design paper.
Government agencies needed spatial databases for infrastructure planning. Logistics companies needed them for routing. Environmental scientists needed them for mapping. All of them became PostgreSQL users because PostGIS only ran on PostgreSQL.
The flywheel started turning: PostgreSQL's extensibility attracted extension developers. Extensions attracted specialized users. Specialized users contributed to stability and funded development. Stability attracted more serious users. More serious users attracted more extensions.
Michael Stonebraker, years later, gave a specific explanation for how PostgreSQL became the dominant open-source database.
"That was a wonderful accident," he said. "Totally unbeknownst to me."
In 2010, Oracle acquired Sun Microsystems, which owned MySQL. The open-source database community — which had relied on MySQL as the free alternative to Oracle — suddenly found itself in a strange position: Oracle now owned both the expensive database and the free one. The motivations for keeping MySQL genuinely free were, at minimum, unclear.
Developers and companies who had been building on MySQL started asking a question they had not asked before: "What else is available?"
PostgreSQL had been there for fifteen years. It was more feature-complete than MySQL. It was more correct. It had ACID compliance and foreign keys and stored procedures and everything MySQL had been deferring for years in favor of raw speed.
And suddenly, for a massive population of developers who had not been paying attention, PostgreSQL was the obvious answer.
The community's careful, unglamorous fifteen years of reliability work turned out to be the most important marketing they could have done.
In 2022, the Stack Overflow Developer Survey — the largest annual survey of software developers in the world — asked developers which databases they most wanted to work with, and which ones they wanted to continue using.
PostgreSQL won both categories. It displaced Redis, which had been the most-loved database for five consecutive years.
It won again in 2023. And 2024. And 2025.
Not just "most popular." Most loved. The distinction matters. It means developers who use PostgreSQL don't just tolerate it — they prefer it. They want to keep using it. They recommend it. When they start a new project, they reach for it first.
DB-Engines, which tracks database popularity across search results, job postings, LinkedIn mentions, Stack Overflow activity, and social media, named PostgreSQL "DBMS of the Year" in 2017, 2018, 2019, 2020, and 2023. Four times in the decade since widespread cloud adoption.
It runs Instagram. Spotify. Reddit. Apple. Skype. Parts of the financial infrastructure of the global economy.
It is the default database for Rails, the default for Django, the default for nearly every modern web framework that has an opinion about which database you should use.
And it is still governed, to this day, by a distributed volunteer organization with a public mailing list as its primary decision-making forum.
What PostgreSQL actually is, technically, is the vindication of ideas that were considered over-engineered in 1986:
MVCC — Multi-Version Concurrency Control. Instead of locking rows when you write to them, PostgreSQL maintains multiple versions of the same data simultaneously. Readers never block writers. Writers never block readers. You can run complex analytics queries against a table while other processes are writing to it. This is why PostgreSQL scales for modern applications in a way that lock-based databases cannot.
Extensibility — The Full Architecture. Custom data types. Custom operators. Custom index methods. Custom functions in Python, JavaScript, Rust, C. Custom foreign data wrappers that let PostgreSQL query external data sources as if they were local tables. The extension ecosystem runs into thousands of published extensions covering every conceivable use case.
pgvector. This is the modern proof of extensibility. As AI applications exploded after 2020, developers needed databases that could store and query high-dimensional vectors — the numerical representations that large language models use. Someone built pgvector as a PostgreSQL extension. It became the default vector database for AI applications. PostgreSQL became the AI database without changing a single line of core code.
Full SQL compliance with decades of careful standards adherence, window functions, CTEs, lateral joins, full JSON support including JSONB binary format with GIN indexing, and the ability to use PostgreSQL as a document database when you need that — without switching databases.
In March 2015, the Association for Computing Machinery announced the 2014 A.M. Turing Award.
The Turing Award is what computing professionals mean when they say "the Nobel Prize of computer science." It is given for contributions of lasting and major technical importance. Previous recipients include the inventors of the internet protocols, the creators of Unix, the designers of the C programming language. The award comes with a $1 million prize, funded by Google.
The 2014 recipient was Michael Stonebraker.
The citation was specific: "for fundamental contributions to the concepts and practices underlying modern database systems."
The ACM press release noted: INGRES, which Stonebraker built at Berkeley in the 1970s, became the foundation for much of the commercial relational database industry. POSTGRES, which he designed at Berkeley in the 1980s, became the foundation for PostgreSQL, which had become by 2015 one of the most widely-used databases in the world.
His reaction, in a subsequent interview: "I didn't expect it to last this long. I thought we'd built a research prototype, proven concepts, and moved on. The fact that people turned it into a production system used by millions? That wasn't the plan."
At 80 years old, Stonebraker is still working. His current project is called DBOS — Database-Oriented Operating System — which inverts the traditional computing stack by building an operating system on top of a database, rather than databases on top of an operating system. Whether this will prove as durable as his previous work is a question for the 2050s.
About stopping: "I can't imagine playing golf three days a week. I like what I do, and I will do it as long as I can be intellectually competitive."
There is a version of this story that is a triumph-of-open-source parable.
There is another version that is a triumph-of-architecture parable — the story of design decisions made at a whiteboard in 1986 that turned out to be correct in ways that only became visible twenty years later, when pgvector made them matter for AI and PostGIS made them matter for geography and TimescaleDB made them matter for time-series and Citus made them matter for distributed computing.
Both versions are true.
But the version that is most true, and least often told, is this: a research project was abandoned. The people who should have continued it — the university, the professor, the commercial entity — moved on. And a group of people who were not paid, were not organized, and had no institutional authority decided that the thing should not die.
Andrew Yu and Jolly Chen, working nights and weekends in 1994, replacing a query language in the guts of a complex system they hadn't built.
Marc Fournier, setting up mailing list infrastructure so a scattered community could coordinate.
Bruce Momjian, learning database internals from scratch by submitting patches to a public mailing list.
Vadim Mikheev, writing code from Russia that made the concurrency model production-grade.
David Yang, suggesting an elephant mascot in April 1997 because elephants never forget.
The community that showed up, over and over, for twenty-five years, not because anyone asked them to.
The internet gave these people a way to find each other. Berkeley gave them code that was worth saving. Stonebraker gave them an architecture that was right before the world was ready for it.
They did the rest.
| Year | Event |
|---|---|
| 1970 | Edgar Codd publishes the relational model paper at IBM |
| 1973 | Stonebraker and Eugene Wong begin INGRES at Berkeley |
| 1974 | First INGRES prototype operational |
| 1980 | Stonebraker co-founds Relational Technology Inc. to commercialize INGRES |
| 1985 | INGRES research project officially ends at Berkeley |
| 1986 | POSTGRES project begins; Stonebraker and Rowe publish the design paper at ACM SIGMOD |
| 1987 | First POSTGRES "demoware" becomes operational |
| 1988 | POSTGRES demonstrated at ACM SIGMOD Conference |
| 1989 | POSTGRES Version 1 released to external users |
| 1990 | Version 2 released with redesigned rule system |
| 1991 | Version 3 released |
| 1992 | POSTGRES becomes primary data manager for Sequoia 2000 climate computing project |
| 1994 | Andrew Yu and Jolly Chen add SQL interpreter. POSTGRES v4.2 — final Berkeley release. Project officially shut down. |
| 1995 | Postgres95 released as open source in May |
| 1996 | Renamed to PostgreSQL. PostgreSQL.org launches October 22. |
| 1997 | Version 6.0 released January 29. PostgreSQL Global Development Group formed. David Yang proposes the elephant mascot. |
| 1999 | Elephant becomes official mascot (October) |
| 2001 | PostgreSQL 7.1 achieves full ACID compliance + Write-Ahead Logging. PostGIS launches. |
| 2003 | PostgreSQL Inc. formed; professional elephant logo designed |
| 2010 | Oracle acquires MySQL via Sun acquisition — PostgreSQL migration wave begins |
| 2015 | Michael Stonebraker receives 2014 Turing Award |
| 2017 | PostgreSQL named DB-Engines DBMS of the Year for the first time |
| 2022 | PostgreSQL becomes the most loved and most wanted database in Stack Overflow Developer Survey |
| 2023 | PostgreSQL becomes the most used database among professional developers |
| 2025 | Fourth consecutive year as Stack Overflow's most loved, most wanted, and most used database |
Michael Stonebraker — Princeton B.S.E., Michigan Ph.D. Joined Berkeley as assistant professor 1971. Invented INGRES (1973), POSTGRES (1986). Co-founded Relational Technology Inc. (1980), Illustra (1992), and later Vertica, VoltDB, Tamr, and others. Received 2014 ACM Turing Award. Still active at 80.
Eugene Wong — Stonebraker's co-creator of INGRES. Two professors with no database experience deciding to prove Codd's theory worked.
Lawrence A. Rowe — Co-author of the 1986 POSTGRES design paper with Stonebraker.
Andrew Yu — Graduate student who, with Jolly Chen, replaced PostQUEL with SQL in 1994, creating Postgres95. Unfunded. Working nights.
Jolly Chen — Co-creator of Postgres95 with Andrew Yu.
Marc Fournier — Set up the mailing list infrastructure for the early PostgreSQL community. Organizational scaffolding without which the scattered volunteers could not have coordinated.
Bruce Momjian — Co-founder and longtime core team member of the PostgreSQL Global Development Group. Began contributing in 1996. Has worked on PostgreSQL for nearly three decades.
Vadim Mikheev — Russian developer whose technical contributions to code stability and concurrency mechanisms were foundational to making PostgreSQL production-ready.
David Yang — Community member who proposed the elephant mascot in April 1997, citing Agatha Christie's Elephants Can Remember.
Jan Wieck — Developer of the Slony-I replication system; named his project after the Russian vocabulary for "elephant" (slon, slony, slonik) when he discovered the name of the PostgreSQL logo file.
Angle 1 — The Abandonment Arc
A university project shut down in 1994. Source code sitting on a server. Two graduate students working nights without pay to replace the query language. The best database nobody had finished building.
Angle 2 — The Architecture Thesis
In 1986, Stonebraker argued databases should be platforms, not products. Everyone thought it was over-engineered. In 2024, pgvector runs on that thesis. He was right before the world was ready.
Angle 3 — The Community Story
No company owns PostgreSQL. No VC funded it. A Canadian set up the mailing list, a Russian fixed the concurrency model, an American learned database internals by submitting patches publicly. That's the development team.
Angle 4 — The Turing Award Irony
The database that won Stonebraker the Nobel Prize of computing is the one he considered a research prototype he expected to be forgotten. The commercial products he actually tried to build and sell are less relevant today.
Angle 5 — The MySQL Accident
Oracle bought MySQL. Developers got nervous. PostgreSQL had been there for fifteen years, better on every technical dimension, waiting for developers to actually look. The accident that started a stampede.
Angle 6 — The Extensibility Dividend
Every time a new use case emerges — spatial data, time-series, vectors for AI — someone builds a PostgreSQL extension. The architecture written in 1986 keeps paying dividends because Stonebraker designed for unknown future requirements.
