What's New in PostgreSQL 18: The 6 Features Worth Upgrading For

CodexFuse Team · 2026-11-06T11:17:37.905Z · 24 min read min read

What's New in PostgreSQL 18: The 6 Features Worth Upgrading For

PostgreSQL 18 is the open-source database's 2025 major release, and it is the biggest architectural change in years. The headline is a new asynchronous I/O subsystem that the PostgreSQL project says can deliver up to 3x read-throughput improvements in certain scenarios, plus uuidv7() for sortable primary keys, virtual generated columns as the new default, and a RETURNING clause that finally shows you the old and new row in one statement. This guide covers what's new in PostgreSQL 18, which minor version to install, and whether you should upgrade, as of November 2026.

If you run your own database, the version you install matters more than the feature list: PostgreSQL 18.0 is a year old, and the current minor is 18.6, which fixes 46 security vulnerabilities the original release shipped with. Read our VPS hosting guide first if you are still choosing the server your database will live on, then use the sections below to decide whether PostgreSQL 18 earns a place on it.

What Is New in PostgreSQL 18?

PostgreSQL 18 is a major release of the world's most widely used open-source relational database, and its headline change is a new asynchronous I/O (AIO) subsystem that lets the server issue several disk reads at once instead of waiting for each one to finish. It also adds uuidv7() for timestamp-ordered UUIDs, virtual generated columns that compute at read time, RETURNING with OLD and NEW row values, OAuth 2.0 authentication for single sign-on, and skip scans that finally use multicolumn indexes when the leading column has no filter. The release was published on 25 September 2025, and it is supported until 14 November 2030.

Six changes define this release, and each one retires a workaround developers have carried for years. Async I/O replaces the one-read-at-a-time pattern that capped scan and vacuum speed. The uuidv7() function replaces generating sortable UUIDs in application code.

Virtual generated columns replace the stored-only columns that made writes pay for values nobody had asked for yet.

The remaining three changes are quieter but just as practical. RETURNING with OLD and NEW collapses the audit pattern of running a SELECT next to every UPDATE into a single statement. OAuth authentication lets PostgreSQL plug into the same single sign-on your company already uses.

Skip scans rescue the multicolumn indexes that sat unused whenever a query skipped the first column.

When Was PostgreSQL 18 Released, and Which Version Should You Install?

PostgreSQL 18 was released on 25 September 2025, so install 18.6, not 18.0. The 18.6 minor shipped on 13 August 2026 and fixes 28 security vulnerabilities, and the minor release before it — 18.5 was never shipped because the project found a regression before it went out. Go straight to the current minor, and keep an eye on the next quarterly minor, which lands on 12 November 2026.

The date matters because a surprising amount of coverage still says 2026. PostgreSQL 18 came out in September 2025, which means it is 407 days after its release at the time of writing, not a fresh launch. That is good news for upgraders: a year of minor releases has already shaken out the early bugs, and the current minor is the stable target.

PostgreSQL's versioning policy supports each major release for five years, so PostgreSQL 18 is supported until 14 November 2030, or 1,876 days of support from its release date. The project recommends always running the current minor release, and it considers minor upgrades less risky than staying on an old minor. The table below is the full minor-release history, with the security fixes each one carried.

The 46 security fixes across the 18.1 to 18.6 minor releases are the strongest argument for installing the current minor rather than the original release. The official notes add up as 2 + 5 + 0 + 11 + 28 = 46, and the August 2026 release alone accounts for 28 of them, including several with high severity scores. The figure 46 is the sum of the official minor-release counts, not a single number the project published, but every component of the sum comes from the project's own release notes.

One date deserves a red circle on your calendar. PostgreSQL 14 stops receiving fixes on 12 November 2026, six days from this article's publication date, so anyone still running PostgreSQL 14 is out of support within the week. If you are on 14, the upgrade question is not about PostgreSQL 18's features; it is about staying on a supported release at all.

How Does PostgreSQL 18's Async I/O Make Reads Faster?

PostgreSQL 18's async I/O subsystem lets the database issue multiple disk-read requests at once instead of issuing one, waiting for it to finish, and only then starting the next. The PostgreSQL project says benchmarking has demonstrated performance gains of up to 3x in certain scenarios, and the subsystem covers sequential scans, bitmap heap scans, and vacuum operations. It is the biggest architectural change in this release, because it attacks a limit every previous version shared: a single backend could only have one read in flight at a time.

That is what postgres 18 async io means in practice: several reads in flight at once.

The mechanism is straightforward. A sequential scan over a large table used to be a strict queue: read a block, process it, read the next block. With async I/O, the scan can keep several reads outstanding, so the disk is working while the CPU processes the previous block.

The same applies to vacuum, which spends much of its time reading pages it needs to clean, and to bitmap heap scans, which fetch scattered heap pages after the index pass.

Three settings control the behaviour. The io_method setting selects the mechanism: worker (background I/O workers), io_uring on Linux, or sync, which is the old behaviour. A new pg_aios monitoring view shows what the subsystem is doing, and the io_uring method is the fastest option where the operating system supports it.

On Linux, io_uring is the method to aim for; on other platforms, the worker method still delivers the concurrency benefit.

Keep the 3x figure in perspective. Treat the 3× figure as the project's benchmark claim for certain scenarios, not a general speedup. The press kit gives no workload, hardware, or methodology, and your own queries will see anything from a large gain on full-table scans to almost nothing on small indexed lookups that never waited on disk.

The honest way to evaluate it is to run your own worst queries with EXPLAIN ANALYZE before and after the upgrade, and note that PostgreSQL 18 now prints buffer counts in EXPLAIN ANALYZE automatically, without the BUFFERS flag everyone used to forget.

What Does uuidv7() Change About Primary Keys?

PostgreSQL 18 adds a uuidv7() function that generates UUIDs ordered by their timestamp, which makes them usable as primary keys without the index fragmentation that random UUIDs cause. A random UUID version 4 scatters every insert across the B-tree, because each new id lands in a random spot and forces page splits. A UUID version 7 starts with a millisecond timestamp, so inserts cluster near each other, the index stays compact, and recently inserted rows sit together in the cache.

The practical change is small and the payoff is large. Where you used to write gen_random_uuid() as a primary-key default, or generate UUIDs in application code and hope the database coped, you can now write uuidv7() as the column default and let the database do it. The ids stay globally unique, like any UUID, so they still work across services and databases that never talk to each other, which is the property an integer sequence can never give you.

PostgreSQL 18 also adds uuidv4() as a plain alias for gen_random_uuid(), so existing code that calls the old function keeps working unchanged. The upgrade question is simple: if your tables already use random UUID primary keys, you do not need to rewrite them, because the old ids keep working. Use uuidv7() for new tables, and consider it first for any table whose insert rate is high enough that index fragmentation shows up in your monitoring.

In short, the postgresql 18 uuidv7 function turns UUID primary keys from a fragmentation problem into a non-issue.

What Are Virtual Generated Columns, and Why Are They Now the Default?

PostgreSQL 18 makes virtual generated columns the default, which means a generated column now computes its value at read time instead of storing it on disk at write time. Generated columns derive their value from other columns in the same row, such as a full_name computed from first_name and last_name, or a line_total computed from quantity and unit_price. Before PostgreSQL 18, that computation always happened at write time and the result was stored, which picked the expensive default: every insert and update paid for a value nobody had asked for yet.

Virtual columns flip the cost to the moment the value is actually read, which is the behaviour most other major databases already use. The trade-off is honest and worth stating once: a virtual column is recomputed on every read, so a value read thousands of times a day costs more over time than a stored one, and virtual columns cannot be indexed, which is the hard limit most schemas hit first. If a computed value is read far more often than its inputs change, keep it stored by writing GENERATED ALWAYS AS (...) STORED explicitly.

One more detail matters for replication. PostgreSQL 18 adds logical replication for stored generated columns, so a subscriber can now receive them. Virtual columns still do not replicate, because there is nothing stored to send, and the subscriber computes them from the replicated base columns instead.

If you replicate, check which kind your generated columns are before assuming they arrive on the other side.

How Does RETURNING With OLD and NEW Work?

PostgreSQL 18 lets the RETURNING clause expose both the previous (OLD) and current (NEW) values of a row, so a single statement hands you the row before and after the change. Before this release, RETURNING could only show the new row, which meant an audit trail needed a trigger, a second SELECT, or a transaction wrapping both, with a race window between them. Now one UPDATE can return both versions of the row, with no second query and no trigger.

The syntax reads naturally. An update that changes a booking status can return old.status and new.status in the same statement, and an application can log the change, publish an event, or show the user what changed, all from the one result set. The feature works for INSERT, UPDATE, DELETE, and MERGE, so a MERGE that inserts some rows and updates others can report both sides of every row it touches.

The whole class of audit pipelines that paired a SELECT with the mutating statement now collapses into the mutating statement alone. That is the real win: fewer round trips, no race between the read and the write, and no trigger to maintain. If your application already has triggers doing this job, leave them alone; triggers still work and still have their place.

Use RETURNING with OLD and NEW for new code, where it replaces the pattern cleanly.

What Does OAuth Authentication Mean for PostgreSQL 18?

PostgreSQL 18 adds a native oauth authentication method that lets users authenticate with OAuth 2.0, which is the protocol that powers single sign-on across most modern software. The method is configured in pg_hba.conf like any other authentication method, but the actual token validation is done by extensions, for identity providers such as Okta, Keycloak, or Microsoft Entra. In practice, that means your database can finally accept the same login your staff already use for everything else, instead of a separate database password per person.

The security gain is centralised identity. When someone leaves the company, disabling their single sign-on account now locks them out of the database too, instead of leaving a database password that has to be hunted down separately. Short-lived tokens replace long-lived passwords, and multi-factor authentication configured once at the identity provider protects the database along with everything else.

OAuth 2.0 is the same protocol family that secures most modern APIs, so if the concepts are new to you, our API beginner guide explains the request-and-response model these systems are built on.

Two cautions belong here. First, OAuth in PostgreSQL 18 needs an extension that validates tokens for your provider, so this is not a switch you flip and forget; plan the extension and the provider configuration as part of the upgrade. Second, database passwords do not disappear overnight: service accounts, replication users, and automated jobs still need credentials, and the md5 password method is deprecated in this release, so move those accounts to SCRAM-SHA-256 while you are making authentication changes anyway.

What Is Skip Scan, and When Does It Help?

PostgreSQL 18 adds skip scans, which let the planner use a multicolumn B-tree index even when the query has no filter on the index's leading column. Before this release, an index on (status, created_at) was useless to a query that filtered only on created_at, because the planner could not jump into the middle of the index. The query fell back to a sequential scan, and the index sat unused half the time.

A skip scan probes each distinct value of the leading column in turn, effectively running one index lookup per value, and the planner now considers that plan.

The classic case is a low-cardinality leading column. An index on (country, signup_date) with a few dozen countries is a good candidate: the planner makes a few dozen probes, one per country, and each probe is an efficient index scan. A leading column with millions of distinct values is a bad candidate, because the probe count explodes and the sequential scan wins again.

The planner decides, so you do not configure anything; you just stop seeing sequential scans on queries that used to ignore a perfectly good index.

Skip scans pair with a second planner improvement in the same release. PostgreSQL 18 can now optimise queries that use OR conditions in a WHERE clause to use an index, where older versions often gave up and scanned. Together, these two changes mean more of your existing indexes get used without any schema change, which is the cheapest performance win an upgrade can give you: no new index to build, no query to rewrite, just a planner that sees more of what is already there.

What Else Changed in PostgreSQL 18?

PostgreSQL 18 features a long tail of smaller changes that are easy to miss behind the six headline features, and several of them change defaults you should know about before upgrading. Page checksums are now enabled by default for clusters created with initdb in PostgreSQL 18, which means new clusters detect disk corruption instead of silently serving bad pages. The md5 password authentication method is deprecated and will be removed in a future release, so SCRAM-SHA-256 is the password method to standardise on.

The wire protocol moves to version 3.2, the first new version since 2003, although clients still default to 3.0 and nothing breaks.

Developers get three smaller gifts. EXPLAIN ANALYZE now reports buffer usage automatically, so the numbers that tell you whether a plan is slow or the disk is slow are no longer hidden behind a flag. A new PG_UNICODE_FAST collation and a casefold() function speed up text comparisons with full Unicode semantics.

Temporal constraints arrive with WITHOUT OVERLAPS on primary and unique keys, so a room-booking table can enforce "one booking at a time" as part of the key instead of a hand-written exclusion constraint.

Operators get their share too. Parallel GIN index builds speed up index creation on large text-search tables. Vacuum now proactively freezes more pages during regular vacuums, which reduces the overhead of aggressive anti-wraparound vacuums later.

And pg_upgrade itself gets faster with many objects, runs its checks in parallel with --jobs, and gains a --swap flag. The table below collects the smaller changes in one place, so nothing important hides in the release notes.

PostgreSQL 18 vs 17: The Honest Comparison

PostgreSQL 18 vs 17 is a comparison between a release that changes how the database reads from disk and a release that refined what was already there. PostgreSQL 17, released in September 2024, brought MERGE with RETURNING, JSON_TABLE, and incremental backup improvements. PostgreSQL 18 adds the async I/O subsystem, which is the first change to the read path itself in years, and a set of developer features that remove daily workarounds.

If you are on 17, the upgrade is about the new features; if you are on 16 or older, it is about those features plus everything 17 added.

The table below compares the two releases feature by feature. The pattern to notice is that PostgreSQL 18's changes are mostly things you can use on day one without redesigning anything: uuidv7() in a column default, a virtual column instead of a stored one, an OLD and NEW in a RETURNING clause. PostgreSQL 17's headline features, by contrast, mostly rewarded new code written against them.

That makes 18 the easier upgrade to justify on a busy team.

One thing the comparison should not hide: PostgreSQL 18 is not the newest major version for long. PostgreSQL 19 is in release-candidate phase, not beta, with RC 1 out on 15 October 2026 and general availability planned for 19 November 2026. That is 13 days from this article's publication date.

If you are planning an upgrade today, 18 is the right target, because 19 is not released yet and a release candidate is not a production database. Upgrade to 18 now, and evaluate 19 after it ships and its first minor arrives.

Should You Upgrade to PostgreSQL 18?

Yes, in most cases, and the timing is better now than it was at launch. PostgreSQL 18 has had a year of minor releases behind it, the current minor is 18.6, and the features that justify the move are things you can adopt gradually: uuidv7() on new tables, virtual columns on new computed values, skip scans with no action at all. The upgrade preserves your planner statistics, so post-upgrade performance should reach its normal level faster than previous major upgrades, which rebuilt statistics from scratch.

Three situations make the answer an unconditional yes. If you run PostgreSQL 14, support ends in six days, so you are upgrading to stay supported, not to chase features. If your workload is scan-heavy or vacuum-heavy, async I/O is the largest single performance change in years and it needs no query rewrites.

If your team uses UUID primary keys, generated columns, or hand-rolled audit triggers, the new features retire real code you maintain today.

Two situations call for patience. If your database is reachable over the internet, sort out remote access first: a static IP guide explains the addressing side, and a VPN beginner guide covers the safer way to reach a database that should never be public. And if you run extensions, check each one publishes a PostgreSQL 18 build before you upgrade, because an extension without a compatible release blocks the whole move.

Extensions are the most common reason a planned upgrade waits a quarter.

How Do You Upgrade to PostgreSQL 18?

Upgrading to PostgreSQL 18 is a standard major-version upgrade, and pg_upgrade does the heavy lifting. The steps below are the shape of the process, not a copy-paste runbook: read the official upgrade documentation for your exact versions, and rehearse the upgrade on a copy of your database first. The rehearsal is where you find the extension, collation, and configuration issues, not on production at midnight.

1. Take a full backup, and verify you can restore it, before touching anything.
2. Install PostgreSQL 18.6, the current minor, alongside your existing cluster.
3. Check every extension for a PostgreSQL 18 build, and upgrade or replace the ones that lack one.
4. Run pg_upgrade with --check first, then for real, using --jobs to parallelise the checks.
5. Start the new cluster, run ANALYZE, and compare your slowest queries with EXPLAIN ANALYZE before and after.
6. Keep the old cluster's data directory until the new cluster has run cleanly for a few days.

PostgreSQL 18's pg_upgrade preserves planner statistics by default, which is the upgrade improvement most people will actually feel. Previous upgrades threw the statistics away, so the first hours after an upgrade ran on a planner guessing blind until ANALYZE rebuilt them. Now the statistics carry over, and the upgraded cluster reaches expected performance much faster.

CodexFuse does not offer a PostgreSQL tool, so this article is a guide, not a product page. The --jobs flag parallelises the pre-upgrade checks, and the new --swap flag handles the directory exchange for you.

Docker users have the simplest path of all: pull the official postgres:18 image, mount your data directory, and let the container do the rest, following our Docker beginner guide if container basics are new to you. The same rule applies either way: rehearse on a copy, keep the backup, and keep the old data directory until you are sure. The numbers below are the ones this article's dates and counts come from, computed from the release calendar rather than typed from memory.

from datetime import date
rel = date(2025, 9, 25)   # PostgreSQL 18 release
now = date(2026, 11, 6)   # this article
eol = date(2030, 11, 14)  # end of support
print("days since release:", (now - rel).days)          # 407
print("days of support:", (eol - rel).days)             # 1876
print("days to PG 14 EOL:", (date(2026, 11, 12) - now).days)  # 6
print("days to PG 19 GA:", (date(2026, 11, 19) - now).days)   # 13
print("CVE total 18.1-18.6:", 2+5+0+11+28)              # 46
print("days from 18.0 to 18.6:", (date(2026, 8, 13) - rel).days)  # 322

One claim deserves a correction before it spreads further. Some coverage says PostgreSQL 18 brings 64-bit transaction IDs, but transaction IDs are still 32-bit in PostgreSQL 18, and the 64-bit patch was rejected for core and lives only in commercial forks. Do not plan capacity around a wraparound fix that does not exist in the release you are installing.

What 18 does improve is the vacuum side of the story: regular vacuums now freeze more pages proactively, which reduces the overhead of the aggressive vacuums that wraparound forces.

Sources

1. Official PostgreSQL 18 press kit — https://www.postgresql.org/about/press/presskit18/ — release date, the up to 3x async I/O claim, uuidv7(), virtual generated columns, RETURNING with OLD and NEW, OAuth 2.0, skip scans, pg_upgrade planner statistics, page checksums by default, md5 deprecation, wire protocol 3.2, PG_UNICODE_FAST, and temporal constraints.
2. Official PostgreSQL versioning policy — https://www.postgresql.org/support/versioning/ — current minor 18.6, support until 14 November 2030, the five-year support policy, and the recommendation to always run the current minor.
3. Official PostgreSQL 18.6 announcement — https://www.postgresql.org/about/news/postgresql-186-1711-1615-1519-1424-and-19-beta-3-released-3365/ — 18.5 skipped because of a regression, 28 security vulnerabilities fixed, over 110 bugs fixed, 13 August 2026 date, and the PostgreSQL 14 end-of-support notice.
4. Official PostgreSQL minor release notes 18.1 to 18.6 — https://www.postgresql.org/docs/18/release-18-1.html and the matching pages for 18.2, 18.3, 18.4, and 18.6 — the CVE counts behind the 46 total: 2, 5, 0, 11, and 28.
5. Official PostgreSQL 19 RC 1 announcement — https://www.postgresql.org/about/news/postgresql-19-rc-1-released-3409/ — release candidate 1 on 15 October 2026 and general availability planned for 19 November 2026.
6. EnterpriseDB, "Celebrating the PostgreSQL 18 Release" — https://www.enterprisedb.com/blog/celebrating-postgresql-18-release — OAuth identity providers (Okta, Keycloak, Microsoft Entra) and the enterprise framing of the release.
7. Bytebase, "What's New in PostgreSQL 18: A Developer's Perspective" — https://www.bytebase.com/blog/what-is-new-in-postgres-18-for-developer/ — the developer framing of uuidv7(), virtual columns, RETURNING with OLD and NEW, and automatic EXPLAIN ANALYZE buffer counts.
8. DevToolHub, "PostgreSQL 18: The 6 Features Worth Upgrading For" — https://devtoolhub.com/postgresql-18-new-features/ — the six-feature framing, async I/O, skip scans, and pg_upgrade planner statistics.
9. AWS Database Blog, "PostgreSQL 18 on Amazon Aurora and Amazon RDS" — https://aws.amazon.com/blogs/database/postgresql-18-on-amazon-aurora-and-amazon-rds-security-monitoring-and-developer-enhancements/ — md5 deprecation, parallel-worker monitoring, COPY improvements, and the pg_upgrade statistics functions.
10. Official PostgreSQL documentation, transaction IDs — https://www.postgresql.org/docs/current/transaction-id.html — the xid type is 32 bits wide, which is the basis for the 64-bit transaction ID correction in this article.

Frequently Asked Questions

What is new in PostgreSQL 18?

PostgreSQL 18 adds async I/O for faster reads, uuidv7() for sortable primary keys, virtual generated columns as the default, RETURNING with OLD and NEW values, OAuth 2.0 authentication, and skip scans for multicolumn indexes. It was released in September 2025, and the current minor is 18.6.

Should I upgrade to PostgreSQL 18?

Yes, in most cases, and especially if you run PostgreSQL 14, which stops receiving fixes on 12 November 2026. Install the current minor, 18.6, rehearse the upgrade on a copy of your database, and check every extension for a compatible build first.

Which PostgreSQL 18 version should I install?

Install the current minor, 18.6, which shipped on 13 August 2026 and fixes 28 security vulnerabilities. The original 18.0 release is a year old, and the 18.5 minor was skipped entirely because of a regression.

Is PostgreSQL 19 out yet?

No. PostgreSQL 19 reached release candidate 1 on 15 October 2026, and general availability is planned for 19 November 2026. Upgrade to PostgreSQL 18 now, and evaluate 19 after it ships.

Does PostgreSQL 18 have 64-bit transaction IDs?

No. The transaction ID type in PostgreSQL 18 is still 32 bits wide, per the official documentation, and the 64-bit patch was rejected for core. What 18 does improve is vacuum, which now freezes more pages proactively.