1986 – 2025

PostgreSQL Versions

Every public release of PostgreSQL — from Michael Stonebraker's POSTGRES research project at Berkeley in 1986, through the 1994 Postgres95 fork and the 1996 PostgreSQL rename, to PostgreSQL 18 in September 2025 — with end-of-life dates, current support state, and the major changes per version. Plus the major-feature arcs (MVCC, write-ahead logging, point-in-time recovery, streaming replication, JSONB, declarative partitioning, JIT, MERGE) and the PGDG governance story.

Era & support

Era

POSTGRES — Berkeley research project, 1986–1994 (POSTQUEL query language)
Postgres95 — 1994–1996, the SQL-replaces-POSTQUEL fork
6.x – 9.x — 1997–2017, the dotted-versioning era under the new PGDG name
Modern (10+) — October 2017 onward, integer-major annual cadence

Support

Current — the latest released major
Maintained — receiving minor releases (bug fixes and security)
EOL — past its five-year community-support window

Postgres ships one new major version per year (typically late September / early October); each major receives five years of community support after its initial GA. See postgresql.org/support/versioning for the live policy.

PostgreSQL version table

Version
PostgreSQL 18
Modern
Current
EOL Nov 2030
Sep 25, 2025
Asynchronous I/O subsystem; UUIDv7 support; OAuth 2.0 authentication; virtual generated columns; skip-scan B-tree index lookups.
  • Asynchronous I/O — new io_method setting (worker or io_uring on Linux) lets backends issue concurrent reads, dramatically reducing wait time on cold-cache scans. The single largest backend-architecture change since parallel query.
  • UUIDv7 support — new uuidv7() function generates time-ordered UUIDs, finally giving Postgres a built-in primary-key generator that works as well as MySQL's auto-increment for index locality without giving up UUID portability.
  • OAuth 2.0 authentication — native client/server support for OAuth bearer tokens via the new oauth auth method, alongside existing SCRAM, GSSAPI, and LDAP options.
  • Virtual generated columns — GENERATED ALWAYS AS (...) VIRTUAL, computed at read time rather than stored. Complements the stored generated columns added in 12.
  • Skip-scan B-tree lookups — the planner can now use a multi-column B-tree index even when the query omits the leading column, by "skipping" through distinct leading-column values. Common pattern in Oracle / SQL Server now lands in Postgres.
  • Better statistics for JOIN selectivity; logical-replication improvements (replication of generated columns, conflict detection in subscribers); EXPLAIN (BUFFERS) on by default.
  • Confirm latest point release at postgresql.org/docs/release.
Version
PostgreSQL 17
Modern
Maintained
EOL Nov 2029
Sep 26, 2024
Incremental backup; MERGE with RETURNING and WHEN NOT MATCHED BY SOURCE; logical-replication failover; JSON_TABLE.
  • Incremental backup — pg_basebackup --incremental writes only blocks changed since the previous backup. Coupled with the new pg_combinebackup tool to stitch incrementals into a full restorable backup. Closes a long-standing gap against MySQL's xtrabackup.
  • MERGE improvements — the SQL-standard MERGE statement (added in 15) gains RETURNING support, WHEN NOT MATCHED BY SOURCE, and views as merge targets.
  • Logical-replication failover — replication slots can now be synchronized to physical standbys, so a logical subscriber survives a primary failover without losing position. The first major step toward production-grade logical-replication HA.
  • JSON_TABLE — the SQL/JSON standard's path-based JSON-to-relational projection finally lands. Joins the SQL/JSON constructors and predicates added across 16 / 17.
  • Per-backend vacuum memory cap (maintenance_work_mem default 64 MB → effectively unlimited via vacuum_buffer_usage_limit); WAL throughput increases on high-concurrency workloads.
  • Removed the venerable adminpack contrib module; --with-llvm is now disabled by default in source builds (JIT still works when explicitly enabled).
Version
PostgreSQL 16
Modern
Maintained
EOL Nov 2028
Sep 14, 2023
Logical replication from standbys; SIMD-accelerated x86 / ARM CRC; bidirectional = / != for arrays; regress_ grant model.
  • Logical replication from physical standbys — subscribers can now connect to a hot-standby publisher, not just the primary. Relieves the primary of replication-slot pressure on multi-subscriber topologies.
  • Parallelized aggregate functions over partitioned tables; parallel FULL / RIGHT joins; parallel STRING_AGG and ARRAY_AGG.
  • SIMD CRC32C — CRC checksum hot path uses x86 SSE 4.2 / ARM CRC instructions, materially reducing CPU on WAL-heavy workloads.
  • SQL/JSON constructors and predicates — JSON(), JSON_OBJECT(), JSON_ARRAY(), JSON_OBJECTAGG(), JSON_ARRAYAGG(), plus IS JSON / IS NOT JSON predicates from the SQL/JSON standard. (JSON_TABLE followed in 17.)
  • pg_stat_io view giving cumulative read/write/extend/fsync counters per backend type and IO context.
  • Server-side load-balancing on the libpq client (multiple host= entries with load_balance_hosts=random).
Version
PostgreSQL 15
Modern
Maintained
EOL Nov 2027
Oct 13, 2022
MERGE statement; sort-performance overhaul; row and column filters in logical replication; regress_ default schema permissions tightened.
  • MERGE statement — the SQL-standard upsert. After two decades of the Postgres-specific INSERT ... ON CONFLICT idiom (which remains supported), MERGE finally lands. Improvements continued in 17.
  • Sort performance — in-memory and on-disk sort algorithms reworked; certain query shapes see 2–4x speedups. Notable outlier: ORDER BY + LIMIT combinations on large data sets.
  • Row and column filters in logical replication — CREATE PUBLICATION ... WITH (publish_via_partition_root = true); per-publication WHERE clauses; explicit column lists in publications. Long-requested feature parity with logical-replication tooling that had been worked around in userspace.
  • Default public schema permissions tightened — non-superusers can no longer create objects in public by default. Fixes a class of multi-tenant security mistakes that had been the canonical Postgres footgun for two decades.
  • Two-phase commit support for logical replication (basis for the failover work in 17).
  • JSON-format log lines (log_destination = jsonlog); structured regress_ permission model.
  • Removed the long-deprecated exclusive backup mode; pg_basebackup and continuous archiving are now the only paths.
Version
PostgreSQL 14
Modern
Maintained
EOL Nov 2026
Sep 30, 2021
SEARCH / CYCLE in recursive CTEs; multirange types; LZ4 TOAST compression; logical-replication two-phase commit foundation.
  • Multirange types — int4multirange, int8multirange, numrange, tstzmultirange, etc. Generalize the range types added in 9.2 to handle non-contiguous spans (a calendar of available time slots, a set of allowed numeric bands).
  • LZ4 TOAST compression — default_toast_compression = lz4 as alternative to the historical pglz codec. ~5x faster compression and decompression, modestly worse ratio. Per-column override available.
  • Recursive CTE SEARCH / CYCLE — SQL-standard syntax for breadth-first / depth-first ordering and cycle detection in WITH RECURSIVE queries.
  • Stored procedures can OUT-bind parameters; RETURN QUERY EXECUTE in PL/pgSQL.
  • Foreign-data-wrapper enhancements: bulk insert via postgres_fdw; parallel sequential scans via FDW.
  • Logical-replication two-phase-commit foundation laid (full feature in 15).
  • Connection-scaling improvements; per-connection memory overhead reduced; pg_stat_statements normalizes constants more aggressively for better grouping.
Version
PostgreSQL 13
Modern
EOL
Nov 13, 2025
Sep 24, 2020
B-tree deduplication; incremental sort; partitioned-table logical replication; parallelized VACUUM.
  • B-tree deduplication — B-tree indexes store one copy of each duplicate value with multiple TID pointers, dramatically reducing index size on low-cardinality columns. Some real-world indexes shrank by 50–75%.
  • Incremental sort — the planner can now use a partial sort if the data is already sorted by a prefix of the requested keys (e.g. an index on (a) when sorting by (a, b)). Common ORDER BY + LIMIT shapes get faster.
  • Logical replication of partitioned tables — publish_via_partition_root option to publish from the parent table even though changes happen on partitions. Production-grade partitioned-table logical replication.
  • Parallelized VACUUM — VACUUM (PARALLEL N) uses worker processes to vacuum index blocks. Materially shortens vacuum windows on large multi-index tables.
  • Trusted extensions (CREATE EXTENSION by non-superusers when the extension is marked trusted = true); SQL-standard FETCH FIRST ... WITH TIES; generate_series() for date / timestamp ranges.
  • pg_stat_progress_basebackup; EXPLAIN shows planning-time WAL records.
Version
PostgreSQL 12
Modern
EOL
Nov 14, 2024
Oct 3, 2019
Generated columns; JSON path queries (SQL/JSON); pluggable table access methods; recovery.conf removed.
  • Generated columns — GENERATED ALWAYS AS (expression) STORED, computed and stored at write time. Virtual (read-time) variant followed in 18.
  • SQL/JSON path queries — jsonb_path_query(), @? / @@ operators, the SQL/JSON path language. Brings jsonb closer to MongoDB-equivalent expressivity for nested-JSON queries.
  • Pluggable table access methods — the TABLEAM API. Foundation for non-heap storage formats (column stores, log-structured stores) without forking PostgreSQL.
  • Partitioning improvements — thousands of partitions with reasonable planner cost; foreign keys pointing to partitioned tables.
  • recovery.conf removed — long-deprecated; standby setup now uses postgresql.conf + recovery.signal / standby.signal files. The single largest break-glass migration of the modern era.
  • REINDEX CONCURRENTLY; VACUUM skips already-frozen pages.
Version
PostgreSQL 11
Modern
EOL
Nov 9, 2023
Oct 18, 2018
JIT compilation; stored procedures with transaction control; partition-by-hash; covering indexes.
  • JIT compilation — LLVM-based JIT compilation of expression evaluation and tuple deforming for OLAP-heavy queries. Opt-in by default in 11; enabled by default for sufficiently expensive plans starting in subsequent releases. Project led by Andres Freund.
  • Stored procedures with transaction control — CREATE PROCEDURE alongside the existing CREATE FUNCTION; procedures can COMMIT and ROLLBACK mid-execution. Closes a long-standing gap against Oracle / SQL Server.
  • PARTITION BY HASH — declarative hash-partitioning alongside the range and list partitioning added in 10.
  • Covering indexes — CREATE INDEX ... INCLUDE (extra_column). Index-only scans now work on more query shapes.
  • Parallel CREATE INDEX; parallel hash joins; parallel sequential scans on partitioned tables.
  • Default partition for ranges (catch-all for values that don't match any explicit partition).
Version
PostgreSQL 10
Modern
EOL
Nov 10, 2022
Oct 5, 2017
Logical replication; declarative table partitioning; quorum-commit synchronous replication; integer-major versioning.
  • The versioning-scheme change — previously, "major version" meant the first two segments (9.5, 9.6); minor was the third (9.5.3). From 10 onward, the major is the integer (10, 11, 12) and the minor is the second segment (10.1, 10.2). The shift was contentious during 9.6 / 10 development; the FAQ at postgresql.org/support/versioning documents the change. Two decades of "9.x" tooling assumptions had to be untangled.
  • Logical replication — per-table row-level publish/subscribe replication, complementing the physical (block-level) streaming replication that landed in 9.0. The first time Postgres had a built-in solution to cross-major-version replication, multi-master scenarios, and selective table replication. Years of Slony / Bucardo / pgLogical work landed in core.
  • Declarative table partitioning — PARTITION BY RANGE and PARTITION BY LIST as native SQL syntax. Replaced the long-running inheritance-and-trigger pattern that had been the de-facto Postgres partitioning recipe for a decade. Hash partitioning followed in 11.
  • Quorum-commit synchronous replication — synchronous_standby_names can now specify "any 2 of 5" rather than a strict ordered list.
  • Parallel index scans, parallel bitmap heap scans, parallel sequential scans across partitioned tables.
  • SCRAM-SHA-256 authentication; renamed xlog to wal across the entire codebase (CLI tools, directories, function names) to match the 9.x community convention.
  • The annual September / October release cadence was now formalized as policy.
October 2017 — The versioning-scheme change. Postgres 10 was the first release where "major" meant the integer (10, 11, 12) rather than the first two dotted segments (9.5, 9.6). The change resolved two decades of mismatch between the project's release cadence and how tooling parsed versions. Rows below this divider use the older 9.x / 8.x / 7.x scheme.
Version
PostgreSQL 9.6
9.x
EOL
Nov 11, 2021
Sep 29, 2016
Parallel sequential scan / aggregation / join; synchronous replication on multiple standbys; pg_visibility.
  • Parallel query — sequential scans, aggregates, and joins gain parallel-worker support. The single largest planner / executor change since 9.0's streaming replication. OLAP workloads see 2–5x speedups on multi-core machines.
  • Multi-standby synchronous replication — synchronous_standby_names = '2 (s1, s2, s3)' committing only when at least two of the named standbys have acknowledged. Foundation for the quorum-commit form added in 10.
  • Wait-event reporting in pg_stat_activity (the basis for the diagnostic discipline DBAs would build on for the next decade).
  • Foreign data wrapper improvements: postgres_fdw can push down sorts, joins, and aggregates.
  • Last release before the 10 versioning-scheme change.
Version
PostgreSQL 9.5
9.x
EOL
Feb 11, 2021
Jan 7, 2016
INSERT ... ON CONFLICT (upsert); GROUPING SETS / CUBE / ROLLUP; row-level security; BRIN indexes.
  • INSERT ... ON CONFLICT DO NOTHING / DO UPDATE — the Postgres-specific upsert syntax. Filled the long-standing gap before MERGE finally landed in 15.
  • Row-level security — CREATE POLICY for table-level row filtering applied to SELECT / INSERT / UPDATE / DELETE. Foundation for multi-tenant Postgres deployments.
  • BRIN indexes — Block Range INdexes; an index that stores a single summary range per heap block range. Tiny indexes for very large tables with naturally-ordered data (timestamps, append-only log tables).
  • GROUPING SETS / CUBE / ROLLUP — SQL-standard multi-grouping aggregates. Long-needed for OLAP workloads.
  • jsonb indexing improvements; TABLESAMPLE clause; foreign data wrapper inheritance.
Version
PostgreSQL 9.4
9.x
EOL
Feb 13, 2020
Dec 18, 2014
jsonb; ALTER SYSTEM; replication slots; logical-decoding plugin API; materialized-view refresh-concurrent.
  • jsonb data type — binary-format JSON with full indexing support (GIN). Distinct from the text-based json type added in 9.2: jsonb normalizes whitespace and key order, deduplicates keys, and supports @> containment / ? existence operators. The single most-cited Postgres feature for "why we picked Postgres over Mongo" the rest of the decade.
  • Replication slots — named state on the primary tracking how far a replica has consumed. Foundation for logical decoding (this release) and logical replication (10.0).
  • Logical-decoding plugin API — the WAL → row-level-change extraction mechanism, exposed for extensions. pglogical / BDR / Bucardo built on this.
  • ALTER SYSTEM — SQL-level configuration via ALTER SYSTEM SET name = value; values land in postgresql.auto.conf. Long-overdue replacement for hand-editing postgresql.conf for everything.
  • REFRESH MATERIALIZED VIEW CONCURRENTLY; WITH ORDINALITY for set-returning functions.
Version
PostgreSQL 9.3
9.x
EOL
Nov 8, 2018
Sep 9, 2013
Materialized views; LATERAL joins; updateable views; postgres_fdw; JSON operators.
  • Materialized views — CREATE MATERIALIZED VIEW. Persistent precomputed query results, refreshed on demand.
  • LATERAL joins — subqueries in FROM can reference columns from earlier FROM entries. SQL-standard from SQL:1999 finally lands in Postgres.
  • postgres_fdw — the foreign data wrapper that makes another Postgres database queryable as if it were local tables. Replaced the older dblink contrib module for most use cases.
  • Auto-updateable simple views (no trigger needed); event triggers; data checksums in initdb.
  • JSON operators (->, ->>, #>) on the text-based json type added in 9.2.
Version
PostgreSQL 9.2
9.x
EOL
Nov 9, 2017
Sep 10, 2012
json data type; index-only scans; range types; cascading replication.
  • json data type — first-class native JSON storage (text-format; the binary jsonb type followed in 9.4).
  • Index-only scans — queries can be satisfied entirely from the index without touching the heap, when the visibility map confirms all-visible pages.
  • Range types — int4range, tstzrange, etc. Foundation for the multirange types added in 14.
  • Cascading replication (a standby can serve another standby).
  • Major lock-contention reductions on multi-CPU systems.
Version
PostgreSQL 9.1
9.x
EOL
Oct 27, 2016
Sep 12, 2011
Synchronous replication; foreign data wrappers (SQL/MED); extensions; UNLOGGED tables; serializable snapshot isolation.
  • Synchronous streaming replication — synchronous_standby_names; commits block until at least one standby has acknowledged the WAL record.
  • Foreign data wrappers — SQL/MED standard implementation. file_fdw, postgres_fdw (in 9.3), and the long tail of third-party FDWs all built on this API.
  • CREATE EXTENSION — the modern extensions framework. Replaced the older contrib-loading pattern; foundation for PostGIS, pg_vector, pg_stat_statements as user-installable extensions.
  • Serializable Snapshot Isolation (SSI) — true serializable transactions without row-level locking. Long-running research effort by Kevin Grittner.
  • UNLOGGED tables; per-column collations; nearest-neighbor index ordering.
Version
PostgreSQL 9.0
9.x
EOL
Oct 8, 2015
Sep 20, 2010
Streaming replication; hot standby; per-column triggers; anonymous code blocks (DO).
  • Streaming replication — physical (block-level) WAL streaming from primary to standby with sub-second lag, replacing the older log-shipping recipe. The single largest HA improvement in Postgres' history.
  • Hot standby — standbys can serve read-only queries while still applying WAL from the primary. Read-replica scale-out without third-party tooling.
  • Per-column update triggers; anonymous PL/pgSQL code blocks (DO statement).
  • 64-bit Windows support.
  • The 9.x line opens; the project's annual-release cadence solidifies.
Version
PostgreSQL 8.4
8.x
EOL
Jul 24, 2014
Jul 1, 2009
Window functions; common table expressions (WITH); recursive queries.
  • Window functions — OVER (PARTITION BY ... ORDER BY ...); ROW_NUMBER(), RANK(), LAG(), LEAD(). SQL:2003-standard analytics finally land.
  • Common table expressions — WITH clauses for non-recursive query factoring; WITH RECURSIVE for graph and tree traversal.
  • Per-database default privileges; column-level GRANT; contrib/pg_upgrade first appears (would graduate to core in 9.0).
Version
PostgreSQL 8.3
8.x
EOL
Feb 7, 2013
Feb 4, 2008
HOT updates; full-text search in core (tsvector / tsquery); XML data type; enum types.
  • Heap-Only Tuples (HOT) — updates that don't change indexed columns avoid index bloat by linking new tuple versions inside the same heap page. Long-running write workloads got materially less vacuum pressure.
  • Full-text search in core — tsvector / tsquery types and the @@ operator graduated from the tsearch2 contrib module to core, with GIN index support.
  • XML data type and SQL/XML operators; enum types; arrays of composite types.
  • UUID data type; updateable cursors.
Version
PostgreSQL 8.2
8.x
EOL
Dec 5, 2011
Dec 5, 2006
RETURNING clause; warm-standby; rule system improvements.
  • RETURNING clause — INSERT / UPDATE / DELETE ... RETURNING ...; finally a way to atomically inspect what was written without a separate SELECT.
  • Warm-standby setup pattern documented as canonical (precursor to streaming replication in 9.0).
  • Generalized inverted indexes (GIN) for full-text search, arrays, and the future jsonb.
Version
PostgreSQL 8.1
8.x
EOL
Nov 8, 2010
Nov 8, 2005
Two-phase commit (XA); SMP scaling improvements; roles replace users / groups.
  • Two-phase commit (XA) for distributed transactions.
  • Roles unified the previously-separate users and groups; modern privilege model dates from here.
  • Materially better scaling on multi-CPU SMP machines; bitmap index scans.
Version
PostgreSQL 8.0
8.x
EOL
Oct 1, 2010
Jan 19, 2005
Native Windows port; Point-in-Time Recovery (PITR); tablespaces; savepoints.
  • Native Windows port — previously Postgres on Windows ran under Cygwin. The native port opened the entire Windows-server developer market and is widely cited as the moment Postgres' adoption broadened beyond the historical Unix base.
  • Point-in-Time Recovery (PITR) — continuous WAL archiving plus restore-to-arbitrary-time recovery. The first time Postgres had a true backup-and-restore story for production HA.
  • Tablespaces — per-table or per-index storage location, allowing multiple-disk deployments.
  • Savepoints (nested transactions); per-table autovacuum.
Version
PostgreSQL 7.4
7.x
EOL
Oct 1, 2010
Nov 17, 2003
Information schema; performance overhaul; SQL-spec IS DISTINCT FROM.
  • Information schema (SQL-spec metadata views).
  • Major query optimizer improvements; subquery flattening; IN rewritten internally.
  • IS DISTINCT FROM for NULL-safe comparison.
Version
PostgreSQL 7.3
7.x
EOL
Nov 27, 2007
Nov 27, 2002
Schemas (namespaces); prepared statements; better dump format.
  • Schemas as a level above tables (the SQL-standard schema_name.table_name dotted reference).
  • Server-side prepared statements (PREPARE / EXECUTE).
  • Dump and restore format reworked; pg_dump output became cross-version-restorable in a stable way for the first time.
Version
PostgreSQL 7.2
7.x
EOL
Feb 4, 2007
Feb 4, 2002
VACUUM without exclusive lock; statistics view system; outer joins via SQL syntax.
  • Non-blocking VACUUM — previously vacuum required an exclusive table lock; this release made it lock-free against readers and writers. A foundational change for production-grade Postgres operations.
  • Statistics view system (pg_stat_* views); improved planner statistics.
  • SQL-standard outer-join syntax (LEFT JOIN etc.) replaced the older Postgres-specific syntax.
Version
PostgreSQL 7.1
7.x
EOL
Apr 13, 2006
Apr 13, 2001
Write-Ahead Logging (WAL); TOAST (large-row storage); SQL-spec join syntax.
  • Write-Ahead Logging (WAL) — the architectural change that gave Postgres durable, crash-recoverable storage. Foundation for every subsequent HA / replication / PITR feature; the most-cited "things finally got serious" milestone in Postgres' history.
  • TOAST — The Oversized Attribute Storage Technique; large field values get pushed out to a side relation. Removed the practical row-size limit.
  • Outer joins via SQL syntax (matured further in 7.2).
  • Postgres' production credibility era effectively starts here.
Version
PostgreSQL 7.0
7.x
EOL
May 8, 2005
May 8, 2000
Foreign keys; SQL92-compliant outer joins; planner overhaul.
  • Foreign keys in core (referential integrity finally a first-class feature).
  • Outer-join syntax aligned with SQL92.
  • Planner overhaul; first version where complex query planning matched contemporary commercial databases.
Version
PostgreSQL 6.5
6.x
EOL
long EOL
Jun 9, 1999
Multi-Version Concurrency Control (MVCC); temporary tables; SELECT INTO.
  • MVCC — Multi-Version Concurrency Control, replacing the older table-locking concurrency model. Readers no longer block writers; writers no longer block readers. The single most architecturally consequential commit in PGDG-era Postgres; the design lineage extends back to Stonebraker's original 1986 POSTGRES paper, but this release made it production-ready.
  • Temporary tables; SELECT ... INTO for derived-table creation.
  • Hot backups (the precursor to PITR's continuous archiving model).
Version
PostgreSQL 6.4
6.x
EOL
long EOL
Oct 30, 1998
Views; PL/pgSQL procedural language; SQL update grammar improvements.
  • Views as a first-class feature.
  • PL/pgSQL — the Oracle-PL/SQL-inspired procedural language that became the canonical way to write Postgres functions.
  • JDBC and ODBC driver maturity; the broader Postgres tool ecosystem starts to land.
Version
PostgreSQL 6.3
6.x
EOL
long EOL
Mar 1, 1998
Subselects; SQL92 entry-level conformance; PL/Tcl as second procedural language.
  • Subqueries (SELECT nested in SELECT / WHERE).
  • SQL92 entry-level conformance milestone.
Version
PostgreSQL 6.2
6.x
EOL
long EOL
Oct 17, 1997
JDBC driver; PL/Perl; constraint trigger support.
  • First JDBC driver; PL/Perl as user-installable procedural language.
  • Constraint triggers; SERIAL column type pseudo-syntax.
Version
PostgreSQL 6.1
6.x
EOL
long EOL
Jun 8, 1997
Geometric data types; better date/time handling.
  • Geometric data types (point, line, polygon) inherited from POSTGRES research.
  • Date/time-handling overhaul.
Version
PostgreSQL 6.0
6.x
EOL
long EOL
Jan 29, 1997
First release under the PostgreSQL name; first PGDG release.
  • First release under the PostgreSQL name — the project had been renamed from Postgres95 to PostgreSQL the previous summer (July 1996) at the suggestion of long-time contributor Tatsuo Ishii, reflecting the project's full SQL conformance and shedding the temporary "95" suffix.
  • First release shepherded by the new PostgreSQL Global Development Group (PGDG) — an informal worldwide volunteer development team; Marc Fournier coordinated the infrastructure handoff from Berkeley.
  • Major performance, reliability, and SQL-conformance improvements across the board; the prior Postgres95 codebase had largely been a research-quality fork.
Version
Postgres95
P95
EOL
long EOL
May 1995
Andrew Yu and Jolly Chen fork POSTGRES at Berkeley; POSTQUEL is replaced by SQL.
  • Postgres95 1.0 released by Andrew Yu and Jolly Chen at Berkeley in May 1995, after they finished a Master's project that replaced the POSTGRES POSTQUEL query language with SQL. This was the moment Postgres became something a working developer could plausibly use as their primary database.
  • Renamed to "Postgres95" partly to mark the radical break from POSTQUEL, partly to track the year (echoing the fashionable "95" suffix on Windows 95, OPENSTEP, etc.).
  • Key changes: SQL replaces POSTQUEL; the AOL-style monitor CLI is rewritten as psql; the GNU autoconf-based build system replaces the original Berkeley Makefiles; the language-and-libraries split that defines Postgres' modern internal architecture starts to take shape.
  • Followed by Postgres95 1.01 through Postgres95 1.09 over the rest of 1995 and 1996. The project moved off Berkeley servers to volunteer-run hosts during this period; the founding of the PGDG and the rename to PostgreSQL came the following summer.
Version
POSTGRES (Berkeley)
POSTGRES
EOL
long EOL
1986 – 1994
Michael Stonebraker's Berkeley research database. POSTQUEL query language; many of Postgres' modern architectural choices originated here.
  • POSTGRES — Stonebraker's "post-Ingres" research database, started at UC Berkeley in 1986 as the successor to Ingres (Stonebraker's 1973 relational database project). Funded by DARPA, ARO, and the NSF.
  • Used the POSTQUEL query language — not SQL. POSTQUEL was Berkeley's QUEL successor with object-relational extensions: user-defined types, inheritance, and rules; many of these ideas survived into modern Postgres but the language itself was replaced.
  • The 1986 SIGMOD paper "The Design of POSTGRES" is the project's foundational document.
  • Released in numbered versions internally: POSTGRES 1 (1989), POSTGRES 2 (1990), POSTGRES 3 (1991), through POSTGRES 4.2 (June 1994). Distributed under a permissive Berkeley license, source available, but research-grade quality.
  • Spawned the commercial Illustra Information Technologies (1992; co-founded by Stonebraker), which was acquired by Informix in 1996. Informix was acquired by IBM in 2001. The POSTGRES research lineage has parallel commercial branches (Informix Universal Server, IBM Informix) distinct from the open-source PostgreSQL line.
  • Stonebraker shut down the Berkeley research project in 1994 to focus on Illustra; Andrew Yu and Jolly Chen forked the codebase into Postgres95 the same year, beginning the open-source line that became PostgreSQL.

Click any row to expand. Each row has a stable id for sharing — e.g. /software/postgres/versions/#postgres-18, #postgres-9-4, #postgres95. Live release / EOL state is documented at postgresql.org/support/versioning.

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 graduate students — Andrew Yu and Jolly Chen — took over the codebase as a Master's project. Their key contribution was replacing the project's homegrown POSTQUEL query language with SQL, 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. Postgres95 1.0 shipped in May 1995 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 project's contributors collectively renamed it from Postgres95 to PostgreSQL — a suggestion attributed to long-time contributor Tatsuo Ishii — reflecting the project's growing SQL conformance and shedding the temporary "95" year suffix. 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, source repository, build farm). 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, no foundation, 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 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, pg_vector, 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.
  • 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) — io_uring-backed concurrent reads; the largest backend-architecture change since parallel query.

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 (2004) — commercial Postgres distribution with Oracle compatibility tooling. Co-founded by long-time committer Bruce Momjian. Acquired Pivotal's Greenplum team in 2020; remains the largest dedicated Postgres company.
  • Greenplum (2003) — massively-parallel-processing fork of Postgres for analytics warehouses. Acquired by EMC in 2010, then VMware (2017), then EnterpriseDB (2020). Open-sourced as Greenplum Database; the fork is several majors behind upstream by design.
  • Citus (2014) — sharding extension for Postgres that made it horizontally scalable without forking. Acquired by Microsoft in 2019; ships as Azure Cosmos DB for PostgreSQL.
  • 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, Tembo, Xata — the 2020s-era Postgres-as-a-service companies, each with different storage/serverless/branching twists, all running unmodified or lightly-extended PostgreSQL upstream.

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 (suggested the PostgreSQL rename in 1996; long-time committer; pgpool author), Marc Fournier (PGDG infrastructure coordinator from the 1996 founding through the 2010s).

Modern Core Team and prolific committers: Tom Lane (the most-prolific committer in PostgreSQL's history; planner and parser maintenance for over two decades; Crunchy Data), Bruce Momjian (longtime community lead and PR voice; EnterpriseDB co-founder; "PostgreSQL Internals" presenter), Peter Eisentraut (release manager for many of the modern majors; Translation Group; standards conformance), Magnus Hagander (PGDG infrastructure lead; pgAdmin), Robert Haas (parallel query implementation; partition planner; EnterpriseDB), Andres Freund (logical decoding; JIT compilation; async I/O in 18; replication; Microsoft), Heikki Linnakangas (replication and recovery; Pivotal; EnterpriseDB).

Deep specialists: Kevin Grittner (serializable snapshot isolation), Álvaro Herrera (autovacuum; partitioning; foreign keys), Tomas Vondra (statistics; multi-column statistics; pgwatch), Stephen Frost (security; row-level security), Joe Conway (PL/R; Crunchy Data), 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), Jignesh Shah (extension framework adoption), Andrew Gierth (range types; advanced SQL features), Jonathan Katz (community advocacy; Crunchy Data), the pg_vector team at Supabase / Crunchy / others (a 2023–2025 wave that turned Postgres into a mainstream vector store for embeddings).

Find your version — in psql or the terminal

The browser cannot detect what version of PostgreSQL is running on your server — there's no header or fingerprint that exposes it. Run one of these in psql or your shell to see your real install.

What's running?

Print the client version, the server version, and the numeric form for tooling.

$ psql --version                       # client version (libpq)
$ pg_config --version                  # build-time version

$ psql -c "SELECT version();"           # full server version string
$ psql -c "SHOW server_version;"         # just the version
$ psql -c "SHOW server_version_num;"     # numeric form (180001 = 18.1)

# Inside psql:
postgres=# \\conninfo                      # shows server, port, version

Pin a project to a specific Postgres

Modern projects pin via the container image tag or the Helm chart values; minor versions within a major are binary-compatible.

# docker-compose.yml
services:
  db:
    image: "postgres:18-alpine"          # floats minor; rebuild for security fixes
    image: "postgres:18.1-alpine"        # pinned exact

# Helm values (bitnami/postgresql, cnpg, etc.)
image:
  tag: "18.1.0"

Minor-version upgrades (18.0 → 18.1) are binary-compatible: stop, swap binaries, restart. Major upgrades (17 → 18) require pg_upgrade or dump/restore.

Install or upgrade a version

Multiple Postgres majors can coexist on the same machine; postgresql@N packages are keg-only on Homebrew for exactly this reason.

# macOS (Homebrew, keg-only formulae for side-by-side majors)
$ brew install postgresql@18
$ brew install postgresql@17              # 17 stays around for pg_upgrade
$ brew services start postgresql@18

# Debian / Ubuntu (PGDG apt repository)
$ sudo apt install postgresql-18 postgresql-17

# Fedora / RHEL (PGDG dnf repository)
$ sudo dnf install postgresql18-server postgresql18-contrib

# Windows (winget)
> winget install PostgreSQL.PostgreSQL.18

# Official installers and full PGDG repo docs:
# https://www.postgresql.org/download/

Upgrade your data to a new major

pg_upgrade moves data from one major to the next without a full dump/restore; link mode swaps file inodes for a near-instant cutover on the same disk.

# Stop both servers first; have the new major already initdb'd.
$ pg_upgrade \\
    --old-bindir=/usr/lib/postgresql/17/bin \\
    --new-bindir=/usr/lib/postgresql/18/bin \\
    --old-datadir=/var/lib/postgresql/17/main \\
    --new-datadir=/var/lib/postgresql/18/main \\
    --link                                  # hard-link instead of copy; near-instant

# Cloud-managed Postgres handles upgrades for you:
#   AWS RDS / Aurora-Postgres   - "Modify" → engine version
#   Google Cloud SQL / AlloyDB   - "Edit" → database version
#   Azure Database for PostgreSQL - portal blade or az CLI
#   Each runs pg_upgrade under the hood with a maintenance window.

Full step-by-step at postgresql.org/docs/current/pgupgrade.html.

Sources: postgresql.org/support/versioning; postgresql.org/docs/release; postgresql.org/about/news; feature matrix; wiki.postgresql.org; Stonebraker's 1986 SIGMOD paper "The Design of POSTGRES"; and the books and contemporaneous reporting cited inline. Last updated May 2026.

Mungomash LLC · More software pages