PostgreSQL 18

PostgreSQL 18 adds an asynchronous I/O subsystem used by operations such as sequential scans, bitmap heap scans, and vacuuming, reducing waits for storage reads on workloads that can benefit from concurrent I/O. B-tree indexes gain skip scans, which can make multicolumn indexes useful for some queries that constrain columns after an unconstrained leading column. The cycle also adds UUIDv7 generation, virtual generated columns whose values are calculated when read rather than stored, and temporal primary-key and foreign-key capabilities for modelling non-overlapping validity ranges. Authentication can use OAuth 2.0, subject to configuring a suitable validation path and identity mapping. These are incremental capabilities over PostgreSQL 17, not reasons to assume that every workload will improve without index, query-plan, and application testing.

PostgreSQL 18 remains within its supported window, so staying on this major line does not by itself create a support-status problem. The practical requirement is to keep applying its maintenance updates, since those updates can contain correctness, security, and stability fixes. Remaining on 18 also means deferring capabilities and performance changes introduced by a later major line when one is selected, and allowing the eventual major-version upgrade to cover a larger change set. Moving immediately has costs as well: extensions, client drivers, authentication integrations, backup tooling, generated-column behavior, and query plans all need validation. A team should therefore treat an upgrade beyond 18 as planned risk reduction and feature adoption, rather than as an urgent response to the status of this line.

If upgrading from an earlier PostgreSQL major line, first confirm that every required extension is available and supported on PostgreSQL 18, and test the application against a copy of production data. Rehearse the chosen upgrade method, normally pg_upgrade for a compatible in-place major upgrade, or logical replication or dump-and-restore where their operational properties are preferable. Compare representative query plans and runtimes before and after the upgrade, especially for queries using multicolumn B-tree indexes, and test backup, restore, failover, monitoring, connection pooling, and authentication flows. Evaluate new features only where they solve a defined problem: test skip-scan plan selection with real statistics, validate OAuth identity mapping end to end, and verify generated-column and temporal-constraint semantics against application expectations. If already on 18, keep current with its maintenance updates and retain a rehearsed upgrade and rollback procedure for a future major-line move.