PostgreSQL 6.0 Released — Berkeley Postgres Reborn as a Rigorous OSS RDB

On 8 July 1996, the open-source community released PostgreSQL 6.0. It was the successor to the UC Berkeley research project Postgres (1986-1994), refashioned through the formal adoption of SQL, the move to a BSD licence, and the migration of development to an external community.

Where MySQL took speed and grabbed the web, PostgreSQL took a different road: the uncompromising RDB. Thirty years on, that purism is the reason the database keeps winning "most loved" surveys.

Prehistory — Stonebraker's Two Berkeley Projects

PostgreSQL's ancestors are two Michael Stonebraker projects at UC Berkeley.

The first, Ingres (1973-1985), was among the earliest academic implementations of Codd's relational model. Built around the relational-calculus-style language QUEL, it incubated talent for Oracle, Sybase, and Microsoft SQL Server (Ingres veteran Bob Epstein founded Sybase, whose code Microsoft would later buy as the basis for SQL Server).

The second, Postgres (1986-1994), was Stonebraker's "post-Ingres"—hence the name. It extended the relational model with user-defined types, user-defined functions, inheritance, and a rule system, becoming one of the earliest "object-relational DBMS" implementations. As a research project, it wound down in 1994.

1994-1996 — Adopting SQL, Opening the Code

In 1994, Berkeley graduate students Andrew Yu and Jolly Chen began replacing Postgres's QUEL interface with SQL. The intermediate version they produced was called Postgres95.

In 1996, development was handed from Berkeley to an external open-source community, and the project was renamed PostgreSQL ("Postgres + SQL"). Marc Fournier, Bruce Momjian, Vadim Mikheev, and Thomas Lockhart joined the core team; on 8 July they released PostgreSQL 6.0.

The licence was BSD-style (later codified as the PostgreSQL Licence)—a near-unrestricted free licence close to MIT. This contrasts with MySQL's GPL/commercial dual licence and allowed unrestricted use inside commercial products. Heroku, Amazon RDS, Aurora, and Google Cloud SQL can run PostgreSQL inside their commercial services precisely because of that BSD choice.

Design Philosophy — ACID and Extensibility

Three pillars characterise PostgreSQL technically.

Strict ACID compliance. Transactions are atomic; the default isolation level is Read Committed, with Serializable available. Concurrency is implemented with MVCC (Multi-Version Concurrency Control), so read transactions do not block writes (the same approach Oracle takes). This was the clear differentiator against pre-InnoDB MySQL.

An extensible type system. Users can add their own types, operators, and index access methods. Inherited from Berkeley Postgres, this design later proved fertile ground for game-changing extensions: PostGIS (geospatial data, 2001), TimescaleDB (time-series, 2017), and pgvector (vector search, 2021-).

Fidelity to the SQL standard. Window functions, common table expressions, JSON, arrays, range types, LATERAL JOIN—PostgreSQL has been the industry's earliest implementer of nearly every ANSI SQL feature. When the requirement is "a DB that behaves exactly as the SQL spec says", PostgreSQL is the first choice.

The 2010s — Toward "Most-Loved DB"

For much of the 2000s, PostgreSQL was described as "MySQL's shadow". Performance tuning was complex, replication was unsophisticated, and GUI tooling thin.

The turning point was PostgreSQL 9.0 in 2010, which finally brought standard streaming replication into the core. The 9.x series (2010-2017) added parallel query, JSONB (binary JSON), logical replication, and logical decoding. The "slower than MySQL" reputation became thoroughly outdated.

In Stack Overflow's Developer Survey from 2018 onward, PostgreSQL overtook MySQL in "most-loved database" rankings. From 2023 through 2025 it has finished first three years running across most-admired, most-used, and most-wanted database categories.

The Cloud and AI Era — PostgreSQL's Second Spring

AWS's Aurora PostgreSQL (2017), Google's AlloyDB (2022), Microsoft's Azure Database for PostgreSQL, and Supabase (2020) all offer PostgreSQL-compatible managed services. Major cloud providers compete to ship PostgreSQL-flavour managed databases because the BSD licence lets them fork and extend the core freely.

Then there is the pgvector boom from 2023: vector-search functionality for LLM RAG (Retrieval-Augmented Generation) ships as a PostgreSQL extension. That has put a serious question to the industry: do we really need dedicated vector databases (Pinecone, Weaviate) when ordinary PostgreSQL can do the job?

Fifty-six years after Codd's relational-model paper of 1970, PostgreSQL—built on two Berkeley research projects, evolved as open source for thirty years—now stretches into the LLM era's vector search. It is a rare case of an academic project growing up to share the stage with the great commercial RDBs.