PostgreSQL 18 Makes the Boring Parts Better

A mature database changes the floor beneath it

PostgreSQL 18 is not a reinvention of Postgres. That is precisely why it is interesting. Released on September 25, 2025, the major version concentrates on work that sits below application features: moving pages from storage, choosing indexes, preserving planner knowledge during upgrades, and making common identifiers cooperate better with B-trees. For a database with decades of accumulated behavior, these changes can matter more than a flashy new query surface.

The headline is a new asynchronous I/O subsystem. PostgreSQL can now issue and combine some read work more effectively for operations including sequential scans, bitmap heap scans, and vacuum. The project reported substantial gains in its own testing, but operators should read that as a reason to benchmark, not as a universal multiplier. Storage, kernel support, cache state, query shape, and concurrency still decide what an application will observe.

PostgreSQL 18 also adds skip scans for multicolumn B-tree indexes. An index whose leading column is not constrained may now help in cases where older planning choices were less attractive. Again, this is an expanded option for the planner, not permission to stop designing indexes deliberately.

The upgrade story is operational, not ceremonial

Major database upgrades are rarely difficult because one command is obscure. They are difficult because extensions, drivers, replicas, backup procedures, query plans, and maintenance windows all meet at once. PostgreSQL 18 improves one important part of that sequence: pg_upgrade transfers most optimizer statistics unless told not to. Earlier upgrades could open successfully and then perform unevenly while fresh statistics accumulated. Preserving more of that knowledge should shorten the uncomfortable period after cutover.

There are boundaries. Explicit extended statistics, extension-defined statistics, and some cumulative statistics are not all transferred. The documentation still directs administrators to regenerate missing and cumulative information after the upgrade. A sensible rehearsal therefore includes:

• checking every extension against version 18;
• comparing representative plans before and after migration;
• timing the statistics refresh on production-shaped data;
• testing backup restoration and rollback, not merely taking a backup.

That list is intentionally unglamorous. PostgreSQL 18 reduces migration friction; it does not turn a stateful system into an ordinary application binary.

Small features meet real application habits

The built-in uuidv7() function addresses a familiar compromise. Random UUIDs are convenient across distributed application processes, but their insertion order is unfriendly to B-tree locality. UUIDv7 retains UUID semantics while incorporating time ordering, which can improve index behavior for newly generated identifiers. Teams still need to decide whether exposing approximate creation order is acceptable and whether every writer will generate the same UUID version.

Virtual generated columns are now the default form of generated column, computing values when read rather than storing them. PostgreSQL 18 also brings OAuth 2.0 authentication and allows OLD and NEW values in RETURNING for data-changing statements. None is a universal reason to migrate alone. Together they show a release tuned to patterns already present in production systems: federated identity, fewer application round trips, and schemas that carry more intent.

Actual use is not speculative. The 2025 Stack Overflow Developer Survey recorded PostgreSQL among the database environments used extensively by a large developer sample. That breadth is why conservative release engineering matters: a planner improvement or migration refinement reaches far more kinds of workload than any single benchmark represents.

Follow the change, then inspect it

A database version is only one part of the working system. pgstream focuses on what happens after rows and schemas begin moving. It consumes PostgreSQL logical replication and can send snapshots and continuous changes to PostgreSQL, Kafka, OpenSearch, Elasticsearch, or webhooks. Its 1.0 direction made schema replication stateless: DDL events are emitted into WAL rather than reconstructed through a maintained schema-log table. That is compelling when downstream systems must follow schema evolution, but it also creates an operational obligation to monitor replication slots, WAL retention, lag, and target compatibility.

For a more immediate view, rainfrog offers a terminal interface for browsing schemas, editing queries, filtering results, and saving history or favorites across several database engines. Its lightweight interface is useful over SSH or for developers who live in a terminal. The honest tradeoff is maturity: rainfrog still calls itself beta, grades database support in tiers, and documents clipboard and geometry-type limitations.

The practical story of PostgreSQL 18 is therefore not “upgrade and become faster.” It is: benchmark the new I/O path, rehearse the migration, observe the change stream, and keep a close inspection tool nearby. Mature infrastructure earns trust by improving those loops without pretending they disappear.