PostgreSQL Versions

The 1986 Berkeley origin and the POSTGRES research years

PostgreSQL's lineage begins in 1986, when Michael Stonebraker — already known for the Ingres relational database he had built at Berkeley starting in 1973 — started a successor project he called POSTGRES (literally "post-Ingres"). The project's design goals went beyond relational: object-relational features (user-defined types, inheritance, rules), better extensibility, and a research vehicle for ideas Stonebraker thought databases should adopt next. The 1986 SIGMOD paper "The Design of POSTGRES" is the foundational document; it covers the concepts that survive in Postgres to this day: rich type system, multi-version concurrency control, the rule system, and SQL's eventual displacement of the project's original POSTQUEL query language.

POSTGRES was funded by DARPA, ARO, and the NSF, and was distributed under a permissive Berkeley license. Internal numbered versions ran from POSTGRES 1 in 1989 through POSTGRES 4.2 in June 1994. The codebase served as a research platform — it was used in production at Berkeley and at a small set of external sites, but it was research-quality code with the rough edges that implies. In 1992, Stonebraker also co-founded Illustra Information Technologies, the commercial company that would eventually take the POSTGRES technology to market; Illustra was acquired by Informix in 1996, and Informix in turn was acquired by IBM in 2001. The Informix Universal Server / IBM Informix product line carries a parallel commercial descent from the Berkeley POSTGRES research; the open-source PostgreSQL line we use today is a separate lineage.

Postgres95 — the 1994 SQL fork

In 1994 Stonebraker shut down the POSTGRES research project at Berkeley to focus on Illustra. Two students in his group — Andrew Yu and Jolly Chen — took over the codebase. Their key contribution was rewriting the parser to accept SQL in place of the project's homegrown POSTQUEL query language, a decision that would define everything that followed: SQL was already the lingua franca of databases, and a research curiosity that spoke only POSTQUEL had no path to mainstream adoption. They renamed the project Postgres95, partly to mark the SQL break, partly to follow the "95" naming convention then in fashion. The first public drop, Postgres95 0.01, is dated May 1, 1995; version 1.0 followed that September, with several practical follow-ups (1.01 through 1.09) over the next year. The project also moved off Berkeley servers during this period to volunteer-run infrastructure, the proximate move that made the next step possible.

The 1996 rename to PostgreSQL and the Global Development Group

In July 1996 the Postgres95 sources were imported into a shared repository run off Berkeley hardware — the point at which the open-source project proper begins — and over the rest of that year the contributors collectively renamed it from Postgres95 to PostgreSQL, reflecting the project's growing SQL conformance and shedding the temporary "95" year suffix. The rename landed in the tree on December 11, 1996, and the version numbers were reset to 6.0 to resume the sequence Berkeley's POSTGRES had begun. The project's own history records the choice collectively — "we chose a new name" — and credits no individual proposer. Around the same time, the project formed an informal worldwide volunteer team that called itself the PostgreSQL Global Development Group (PGDG), with Marc Fournier coordinating infrastructure (mailing lists, ftp site, source repository). The first release under the PostgreSQL name was 6.0, in January 1997.

The PGDG has been the project's governance ever since. It has no corporate parent and no formal voting structure on most decisions; it operates on a long-running culture of mailing-list-based discussion and a small core team that ratifies contentious calls. The one piece of formal legal machinery is deliberately narrow: the PostgreSQL Community Association (PGCA), a non-profit the core team chartered in 2011 to hold and defend the project's trademarks and brand assets, funded by corporate and individual sponsorship and chaired by core-team member Dave Page. It does not set technical direction, own the source, or employ the developers — the mailing lists still do all of that. The model is widely cited as one of the most stable open-source-database governance arrangements in the industry — PostgreSQL has weathered several waves of well-funded commercial would-be successors (EnterpriseDB, Greenplum, the cloud-managed-Postgres era) without fragmenting, and remains the canonical upstream for all of them.

The architectural arc — MVCC, WAL, and the modern foundation

Postgres' modern architecture didn't arrive in one release; it accumulated. The two most consequential pieces both landed in the late 1990s and early 2000s.

Multi-Version Concurrency Control (MVCC) shipped in 6.5 (June 1999), although the design lineage goes back to Stonebraker's original POSTGRES paper. Under MVCC, readers see a snapshot of the database as of when their transaction started, and writers create new row versions rather than blocking readers. The result — readers don't block writers, writers don't block readers — is the property every modern database is judged against. Postgres' MVCC implementation has been evolved continuously since (HOT updates in 8.3, freeze-map optimization in 9.6, the visibility-map machinery that makes index-only scans possible), but the architectural commitment was 6.5.

Write-Ahead Logging (WAL) shipped in 7.1 (April 2001). WAL is the durable log of every change Postgres makes to data files; the database can crash and recover by replaying the log from the last consistent checkpoint forward. Every subsequent piece of high-availability infrastructure — PITR (8.0), streaming replication (9.0), logical decoding (9.4), logical replication (10.0), incremental backup (17.0) — is built on WAL. 7.1 is widely cited as the moment Postgres became a serious production database; the prior 7.0 / 6.x line had usable concurrency via MVCC but no real durability story.

The major-feature arc

Beyond MVCC and WAL, the headline features that define modern Postgres landed across two decades:

• Foreign keys in 7.0 (May 2000) — first-class referential integrity.
• Native Windows port + PITR + tablespaces in 8.0 (January 2005) — the broadest adoption-expanding release of the 8.x line.
• Window functions and CTEs in 8.4 (July 2009) — SQL:2003 analytics finally land; WITH RECURSIVE for graph and tree traversal.
• Streaming replication and hot standby in 9.0 (September 2010) — the most-cited HA milestone.
• Foreign data wrappers and extensions framework in 9.1 (September 2011) — the SQL/MED API and CREATE EXTENSION; foundation for PostGIS, pgvector, pg_stat_statements as installable extensions.
• JSONB in 9.4 (December 2014) — binary-format JSON with full GIN indexing; the single most-cited Postgres feature for "why we picked Postgres over Mongo" in the 2015–2020 era.
• Parallel query in 9.6 (September 2016) and 10 (October 2017) — multi-core scaling for sequential scans, aggregations, and joins.
• Logical replication and declarative partitioning in 10 (October 2017) — per-table publish/subscribe; PARTITION BY RANGE / LIST / HASH.
• JIT compilation in 11 (October 2018) — LLVM-based JIT for expression evaluation; led by Andres Freund. Enabled by default for expensive plans through the 12–18 line; the 19 beta (June 2026) reverses course and ships JIT disabled by default, reflecting years of mixed real-world results on the cost-threshold heuristic.
• MERGE statement in 15 (October 2022) — SQL-standard upsert; complemented the long-running INSERT ... ON CONFLICT idiom (still supported).
• Incremental backup in 17 (September 2024) — pg_basebackup --incremental + pg_combinebackup.
• Asynchronous I/O in 18 (September 2025) — concurrent reads issued through the new io_method setting, which defaults to a pool of I/O worker processes and can use Linux io_uring on builds compiled with liburing; the largest backend-architecture change since parallel query. The 19 beta (June 2026) extends it with auto-scaling io_method=worker pools (io_min_workers / io_max_workers) and AIO statistics in EXPLAIN ANALYZE.

The October 2017 versioning-scheme change

For two decades, Postgres had used dotted-version "majors": 6.5 was a major, 6.5.3 was a minor; 9.6 was a major, 9.6.5 was a minor. Most operational tooling (linker shared-library naming, package managers, monitoring) coded around the assumption that the first two segments were the major version. By the mid-2010s the version numbers were running into ergonomic problems: 9.6 sounded like a minor bump after 9.5 even though it was a full major, and the project was visibly going to need to follow 9.x with something that didn't sound smaller. Discussion ran through 9.6's development cycle and concluded with a switch: from PostgreSQL 10 (October 2017) onward, the major version is an integer (10, 11, 12) and the minor is the second segment (10.1, 10.2). The FAQ at postgresql.org/support/versioning documents the change. Lots of tooling needed to be updated; in 2026 the long tail of fixes is mostly behind us, but bash one-liners that cut -d. -f1,2 on a Postgres version string still occasionally bite users.

Commercial forks and the cloud-managed Postgres era

Postgres' permissive license has produced a long tail of commercial forks and managed services. The earliest was the Berkeley spin-out Illustra (1992 → Informix 1996 → IBM 2001) on the POSTGRES research lineage. The open-source PostgreSQL line spawned its own commercial branches over the next two decades:

• EnterpriseDB (March 2004) — commercial Postgres distribution with Oracle compatibility tooling, co-founded by Andy Astor and Denis Lussier. Absorbed the UK consultancy 2ndQuadrant — Simon Riggs' replication shop, home of BDR and pglogical — in September 2020; remains the largest dedicated Postgres company, and employs several Core Team members and major contributors (Bruce Momjian, Peter Eisentraut, Robert Haas, Andrew Dunstan, Álvaro Herrera).
• Greenplum (2003) — massively-parallel-processing fork of Postgres for analytics warehouses. EMC bought it in 2010 and folded it into Pivotal, the EMC/VMware spin-out stood up across 2012–13; it passed to VMware with the December 2019 Pivotal acquisition, then to Broadcom with VMware in November 2023. Pivotal had open-sourced the engine in 2015, but Broadcom closed it again in May 2024 — the public gpdb repository was archived read-only on May 24, 2024 and releases now ship only inside Tanzu Data Suite. The community fork Apache Cloudberry — still an Apache incubator project, not yet a top-level one — carries the open-source line forward. Either way the fork runs several Postgres majors behind upstream by design.
• Citus (2011) — sharding technology that made Postgres horizontally scalable. Citus Data shipped a fork first; it "unforked" into a pure Postgres extension and open-sourced the result in March 2016, which is the model the rest of the ecosystem copied. Acquired by Microsoft in 2019. It shipped as Azure Cosmos DB for PostgreSQL, which Microsoft has since put on a retirement path and no longer recommends for new projects; the extension now lands in Azure Database for PostgreSQL as the Elastic Clusters feature.
• Postgres-XL / Postgres-XC — multi-master MPP forks that ran in parallel to Citus's extension-based approach; less commercially successful.
• AWS Aurora-Postgres (2017) — AWS's managed PostgreSQL with proprietary storage layer that decouples compute from storage. The cloud-managed-Postgres era's most commercially successful product.
• Google AlloyDB (2022) — Google Cloud's Aurora competitor with similar storage decoupling.
• Neon, Supabase, Crunchy Bridge, Xata — the 2020s-era Postgres-as-a-service companies, each with different storage/serverless/branching twists, all running unmodified or lightly-extended PostgreSQL upstream. Two were absorbed by analytics platforms in 2025: Databricks agreed to acquire Neon in May 2025 (reported at roughly $1B), and Snowflake announced its acquisition of Crunchy Data at its June 2025 user conference — in both cases buying a managed-Postgres operator to sit alongside a warehouse rather than forking the engine. Tembo left the category outright: it dropped its hosted-Postgres product in 2025 and repositioned as a cloud coding-agent platform.

Notably, none of the major Postgres forks have produced a long-running upstream-divergent codebase the way MariaDB and MySQL went their separate ways after the 2009 Oracle acquisition. The PostgreSQL upstream has remained the canonical home for the project's evolution, and the commercial ecosystem has organized itself around extensions, managed-service operators, and storage-layer plugins rather than language or query-engine forks.

People who actually shaped Postgres

Berkeley / origin era: Michael Stonebraker (creator of POSTGRES at Berkeley; 2014 Turing Award; co-founder of Ingres, Illustra, Vertica, VoltDB, Tamr, SciDB, and the broader database-startup-of-startups arc), Andrew Yu and Jolly Chen (authored the Postgres95 fork that replaced POSTQUEL with SQL), Tatsuo Ishii (multi-byte character support; CREATE CONVERSION; pgbench; the Japanese documentation translation; Pgpool-II author), Marc Fournier (PGDG infrastructure coordinator from the 1996 founding through the 2010s — mailing lists, ftp site, source repository, websites).

Modern Core Team and prolific committers: Tom Lane (the most-prolific committer in PostgreSQL's history; planner and parser maintenance for over two decades; Snowflake), Bruce Momjian (a co-founder of the PostgreSQL Global Development Group — not of EnterpriseDB, which he joined later; maintains the TODO list, applies patches, and is the project's most-travelled speaker; EDB), Peter Eisentraut (build system, porting, documentation, and the internationalization effort; served on the PostgreSQL 10 release-management team; EDB), Magnus Hagander (the Win32 port and the authentication system; postgresql.org web and project infrastructure; Redpill Linpro), Robert Haas (principal author of parallel query; also unlogged tables, index-only scans, and 17's incremental backup; EDB), Andres Freund (logical decoding; JIT compilation; async I/O in 18; replication; Microsoft), Heikki Linnakangas (replication and recovery; two-phase commit; Neon).

Deep specialists: Kevin Grittner (serializable snapshot isolation), Álvaro Herrera (autovacuum; partitioning DDL; BRIN indexes), Tomas Vondra (CREATE STATISTICS and multi-column statistics; ANALYZE distinct-value estimates), Stephen Frost (security; row-level security), Joe Conway (PL/R; dblink; Amazon RDS Open Source Databases), Greg Stark (planner internals), Andrew Dunstan (build infrastructure; PL/Perl), Dave Page (pgAdmin; PGDG infrastructure), Simon Riggs (synchronous replication; 2ndQuadrant; EnterpriseDB; passed away in 2024).

Extensions ecosystem: Paul Ramsey and Regina Obe (PostGIS), Andrew Gierth (grouping sets; ordered-set aggregates; hstore enhancements), Jonathan Katz (community advocacy; Core Team; pgvector contributor; Databricks), Andrew Kane (author and maintainer of pgvector, the extension that turned Postgres into a mainstream vector store for embeddings across the 2023–2025 wave).