PostgreSQL

BERKELEY, CA — Before it became the backbone of modern internet infrastructure, before major institutions staked their data architectures on it, and before the elephant logo became a familiar sight in server rooms worldwide, PostgreSQL endured more than two decades of reinvention, academic intrigue, and near-extinction. Its story, stretching back to 1973, is less a corporate origin myth than a picaresque tale of a piece of software that simply would not stay buried.

Act I: INGRES and the Berkeley Crucible (1973–1985)

The story does not begin with PostgreSQL. It begins in an office at the University of California, Berkeley, where a young professor named Michael Stonebraker and his colleague Eugene Wong launched a project in 1973 called INGRES (Interactive Graphics and Retrieval System). At the time, the relational model was barely three years old, a theoretical curiosity proposed by IBM researcher Edgar Codd. Stonebraker and Wong decided to build a working relational database from scratch.

For over a decade, INGRES grew into one of the most important database systems in the world, rivaling IBM’s own efforts. But by the mid-1980s, the focus of database research was shifting. Stonebraker and his team wanted to tackle new technical frontiers: extending database support beyond traditional business data to handle complex objects, geographical data, CAD/CAM systems, and documents. The relational model had been proven; now, it needed to evolve.

Act II: POSTGRES and the “Next Generation” (1986–1994)

In 1986, implementation began on POSTGRES (POST INGRES), led by Stonebraker and a rotating cast of graduate students at Berkeley. The mission was audacious. The original query language wasn’t SQL at all, but POSTQUEL, built around a powerful rule system that let users define how the database should react to events. The data model pioneered an object-relational approach, allowing users to teach the database new data types and inheritance structures without touching the core code. Meanwhile, the storage system introduced experimental concepts like versioning and no-overwrite storage.

It was, by many accounts, brilliant. It was also notoriously difficult to maintain. Graduate students cycled through the project in two- and three-year stints, each inheriting a codebase half-documented and full of idiosyncrasies. The rule system, while theoretically elegant, was complex to debug, and performance often lagged.

By 1992, the Berkeley POSTGRES research effort was winding down. That August, Stonebraker co-founded Illustra Information Technologies to commercialise object-relational database technology derived from the research. He remained a Berkeley professor, continuing to teach there until his retirement around 2000, but the university POSTGRES project officially ended with the release of Version 4.2 in 1994. (Illustra would later be acquired by Informix, whose database business ultimately went to IBM.)

Act III: Abandonment and Resurrection (1994–1996)

With the academic project concluded, POSTGRES could have easily faded into obscurity. Instead, it was saved by its licensing. The Berkeley code was available under an unusually permissive licence, allowing others to use, modify, and redistribute it without putting control of the project in the hands of a single commercial vendor.

In 1994, two graduate students, Andrew Yu and Jolly Chen, took initiative. Recognising that POSTQUEL, for all its theoretical power, limited its accessibility and compatibility with the wider database world, they added a SQL interpreter to the front end. The resulting system, renamed Postgres95, was subsequently released to the web.

Rather than walking away, Yu and Chen maintained the project and its mailing lists while finishing their Berkeley work. The public release had effectively been an afterthought, and its subsequent popularity surprised them. As they graduated and moved on, they handed an already-growing community over to a wider circle of volunteers.

Act IV: A Name, and a Second Life (1996–Present)

The transition to community stewardship crystallized on 8 July 1996, when Marc Fournier established the first public CVS server for the code. The community would later treat this date as the effective birthday of the community-developed PostgreSQL project.

Shortly after, the volunteers made a symbolic but important decision: they renamed Postgres95 to PostgreSQL, acknowledging that SQL was no longer a bolt-on afterthought but the system’s native tongue. The version numbering was not reset; the community deliberately started PostgreSQL at version 6.0, restoring the sequence from the final Berkeley releases. The elephant logo—later affectionately named Slonik by the community—became a familiar mascot, though its exact early history is less cleanly documented than the code itself.

The years that followed were a slow, grinding rebuild. The storage manager was rewritten. The query planner was overhauled. The old row-level instance rule system was removed in 1995, but the query-rewrite rule system survived—and in fact, modern SQL views rely on it to this day. For years, PostgreSQL carried a reputation as the “serious free database” that was also, by common complaint, slow and perpetually one version away from being production-ready.

That reputation stuck long after it ceased to be true.

Epilogue: The Ghost of POSTGRES

Today, PostgreSQL is an open-source relational database of choice for many people and organisations worldwide. It powers specific, documented deployments within the U.S. Federal Aviation Administration, underpins massive financial and tech infrastructures, and serves as the default data store for countless modern applications.

No single company owns PostgreSQL; its development is stewarded by a global community, and its permissive licence has allowed the software to remain freely usable, modifiable, and distributable.

And yet, traces of the old POSTGRES remain. The system catalogs. The extensible type system. The procedural language hooks. The very architecture that allows a user to write a custom indexing method and plug it into the core engine—that is the ghost of Berkeley’s 1980s POSTGRES research, still running, still compiling, and still answering queries four decades after the project’s implementation began, protected by the permissive licensing tradition that helped make its survival possible in 1994.

The database that refused to die is, in its own quiet way, still the one Stonebraker’s students built. It has simply been rebuilt, board by board, around them.