September 2023, Revisited: PostgreSQL 16 and the Art of the Unglamorous Release

Our Three-Year Retrospective reaches September 2023 and one of our favorite kinds of release: PostgreSQL 16, which arrived on September 14 with no single headline feature and a dozen improvements that working database teams would lean on for years. While the rest of the industry spent 2023 arguing about AI, Postgres did what Postgres does every September — shipped a major version on schedule, deepened its replication story, and quietly extended its lead as the default database for new applications.

Logical replication grows a second leg

The feature that mattered most operationally was logical replication from standbys. Before 16, logical replication subscribers had to connect to the primary, which meant your CDC pipelines, downstream analytics feeds, and cross-cluster replication all added load exactly where you could least afford it. Postgres 16 let standbys serve as logical replication sources, so you could push that decoding work to a replica — and slots on the standby survived sensibly through failover-adjacent scenarios that previously required careful manual choreography.

The same release sped up the subscriber side: large transactions could now be applied in parallel by multiple workers, and tables could be copied in binary format during initial sync. For teams using logical replication as a near-zero-downtime major-version upgrade path — already the standard playbook by 2023 — every one of these improvements compounded.

pg_stat_io: finally seeing what the I/O system is doing

The observability win was pg_stat_io, a new system view that broke down I/O by backend type, target, and context — reads, writes, extends, evictions, and reuses, separated by whether they came from regular backends, autovacuum, the checkpointer, or bulk operations. Before this view, answering "is autovacuum responsible for this I/O spike?" involved educated guessing across several indirect signals. After it, the answer was a query.

SELECT backend_type, object, context, reads, writes, extends
FROM pg_stat_io
WHERE backend_type = 'autovacuum worker'
ORDER BY reads DESC;

This is the kind of feature that never makes a conference keynote and shows up in every serious incident review afterward. In our administration courses, the before/after on pg_stat_io became a teaching moment about why instrumentation belongs in the database engine, not bolted on around it.

Performance and the long SQL/JSON march

Postgres 16 widened parallelism — FULL and RIGHT outer joins could now execute in parallel, aggregates like string_agg and array_agg could be parallelized — and added CPU-level SIMD acceleration for common operations on x86 and ARM. None of these doubled anyone's throughput; together they shaved real percentages off real workloads for free.

On the standards front, 16 continued the multi-release implementation of SQL/JSON: constructor functions like JSON_ARRAY and JSON_OBJECT, the IS JSON predicate, and assorted conformance work. The big JSON_TABLE payoff was still a release away, but the direction was visible — Postgres was methodically absorbing the features that once justified reaching for a document database. Add libpq load balancing across multiple hosts and regular-expression matching in pg_hba.conf, and you had a release with no fireworks and no filler.

Looking back from June 2026

PostgreSQL 16 aged exactly as expected, which is the highest compliment a database release can earn. The standby-replication work became the foundation that later releases built on, pg_stat_io became muscle memory for anyone doing performance triage, and the broader 2023 trend it represented — Postgres as the default substrate for everything, including the vector workloads that were about to explode — only accelerated. Three years on, the September release cadence keeps rolling, and 16 sits in that comfortable middle age where most production fleets have passed through it.

If your team runs Postgres in production, the topics this release touched — replication topology, vacuum behavior, I/O observability, upgrade strategy — are the core of PostgreSQL for Administrators. And for application developers who want to actually use the SQL/JSON features and understand what the database is doing under their ORM, PostgreSQL for Python Programmers approaches the same engine from the other side of the connection.