PostgreSQL 18: five changes worth testing on your database

PostgreSQL 18 was released on September 25, 2025. Its release notes cover several independent directions: asynchronous I/O for selected read and vacuum operations, B-tree skip scan, timestamp-ordered uuidv7(), virtual generated columns, OAuth support, and temporal constraints. [1] This is not one large feature to enable with a checkbox. It is a set of capabilities that each need to be compared with a schema, query plans, and operating environment.

The worst way to assess the upgrade is to say ‘Postgres 18 is three times faster’. The PostgreSQL Project reports up to 3× improvements in certain storage-read scenarios, but that result belongs to specific I/O conditions. [2] A query bound by CPU, locking, network latency, a poor index, or a slow upstream service will not change automatically.

A better reason to upgrade is a specific pain the release may address: large scans and vacuum work, random UUID primary keys on a table with active inserts, queries filtering a non-leading column of a multicolumn B-tree, or a need to connect clients through a corporate OAuth flow.

Every capability below has a clear test. If you do not have that test, it should not be the main reason for an upgrade.

UUIDv4 is useful as a distributed identifier, but its random order spreads new entries throughout a B-tree. uuidv7() includes a time component, so new values mostly move in one direction. PostgreSQL 18 ships the function in core. [1] For new external identifiers, it is often a better default than an application-generated UUIDv7 or a separate extension.

‘Mostly’ matters here. UUIDv7 does not guarantee absolute order across every concurrent write, solve contention on a hot index, or replace sensible partitioning. It gives a key whose time order aligns better with insertion order. Look for the gain in the actual write-path metrics, not in the appearance of the ID.

For an established system, the calmer approach is often hybrid: historic UUIDs remain while new tables or entities use UUIDv7. Replacing a primary key at scale touches foreign keys, caches, API contracts, replication, and backup processes. A database release alone is not a reason to take that risk.

PostgreSQL lists three main paths between major versions: dump/restore, pg_upgrade, or logical replication. [1] The choice depends on acceptable downtime, data size, and rollback requirements.

PostgreSQL 18 adds OAuth support, and libpq implements an optional Device Authorization client flow. [3] That is useful where database access needs corporate identity, scopes, and short-lived tokens. Not every driver or connection path will support it at once, so a compatibility test is required.

The release also continues the move away from md5 password authentication; MD5 support is planned for removal in a future major release. [1] This is a useful time to check whether every client supports SCRAM, where credentials live, how access rotates, and which service accounts still bypass ordinary rules.

PostgreSQL 18 gives enough reasons to place an upgrade on a roadmap. The strongest reason will differ by system: I/O and maintenance in one, UUIDv7 for new write-heavy tables in another, multicolumn indexes elsewhere, and OAuth in another. None of these removes the need for staging and a baseline.

After a pilot, the result should be specific: upgrade because critical scans became cheaper; use UUIDv7 only for new tables; keep the current indexes; defer OAuth until clients are ready. That decision list is more useful than a broad claim that a new version is ‘faster’.