PostgreSQL 18 landed on September 25, 2025. Database administrators and developers have been waiting for these major improvements.
This version introduces 202 new features, which is a 25% jump from the last release.
The biggest upgrade? The new asynchronous I/O system. It boosts database performance by handling input and output operations more efficiently.
PostgreSQL 18 adds native support for UUIDv7, virtual generated columns, and improved logical replication for sequences. These changes finally address some long-standing headaches in database operations.
The release zeroes in on performance for both transaction processing and analytics. With 110 contributors, PostgreSQL 18 stands out as one of the most comprehensive updates in years.
Table of Contents
Key Takeaways
- PostgreSQL 18 introduces asynchronous I/O technology that noticeably improves performance and cuts latency
- The release packs in 202 features, including better logical replication, UUIDv7 support, and virtual generated columns
- Performance tweaks benefit both transaction and analytical workloads
What’s New in PostgreSQL 18
PostgreSQL 18 brings asynchronous I/O, virtual generated columns, and UUIDv7 support as headline features. The release builds on PostgreSQL 17’s foundation, but with even more performance gains and developer-focused tweaks.
Highlights of Major Changes
Asynchronous I/O (AIO) is the big story here. This subsystem improves performance for sequential scans and heavy data operations.
The database now supports virtual generated columns. These columns calculate values on-the-fly instead of storing them, saving disk space but keeping queries flexible.
UUIDv7 support is another highlight. The new format includes timestamps and outperforms older UUID versions, making it a better fit for indexing and sorting.
Skip scans help optimize index usage when queries skip over some columns in multi-column indexes. Queries run faster without piling on extra indexes.
The pg_stat_io view now gives detailed insights into read and write I/O. Admins can monitor buffer activity, relation types, and timing stats without extra tools.
Temporal constraints let you manage time-based data relationships. These constraints make sure your data stays consistent across different time periods.
PostgreSQL 18 also improves parallel processing for data ingestion. Large data loads now use multiple CPU cores more efficiently.
Comparison with PostgreSQL 17
PostgreSQL 18 builds right on top of the performance foundation from PostgreSQL 17. While version 17 focused on query optimization and better parallel processing, 18 targets I/O and storage efficiency.
The asynchronous I/O system is the biggest difference. PostgreSQL 17 used traditional synchronous I/O, which could bottleneck under heavy loads.
Virtual generated columns are brand new in 18. Before this, users had to rely on stored generated columns or handle calculations in their application code.
PostgreSQL 17 only supported UUID versions 1-4. Version 18’s UUIDv7 cuts down index fragmentation and speeds up inserts.
Skip scan functionality is also new. PostgreSQL 17 needed full index scans or extra indexes for similar queries.
Release Dates and Support Timeline
PostgreSQL 18 followed a structured beta testing process in 2025. Beta 1 arrived on May 8, followed by Beta 2 on July 17.
Beta 3 dropped on August 14, and the release candidate appeared on September 4 for final testing.
The official PostgreSQL 18 release happened on September 25, 2025. This keeps up PostgreSQL’s tradition of big September releases.
PostgreSQL 18 gets the usual five-year support lifecycle. Users can count on security updates and bug fixes through September 2030.
The development team relied on the commitfest process to review and add new features. Multiple commitfests in 2024 and early 2025 shaped the final release.
Organizations should plan their migration timelines based on their own needs. PostgreSQL 17 remains fully supported during the transition.
Core System Improvements
PostgreSQL 18 brings some big system-level changes that boost database performance and reliability. The new asynchronous I/O system speeds up data access, while backend storage and autovacuum processes get smarter.
Asynchronous I/O Enhancements
PostgreSQL 18 finally brings real asynchronous I/O, replacing the old workarounds. The new AIO subsystem lets the database juggle multiple I/O operations without blocking other processes.
This feature brings a noticeable speed boost for I/O-heavy workloads. Database operations keep moving even while waiting for disk reads and writes.
Key benefits:
- Shorter wait times for disk operations
- Better CPU use during I/O
- Higher overall throughput
This infrastructure isn’t limited to just basic I/O. Several parts of PostgreSQL now use the AIO system for better performance across the board.
Both OLTP and analytical workloads benefit, since the new system cuts down the bottlenecks from synchronous I/O in busy databases.
Backend and Storage Updates
PostgreSQL 18 brings backend improvements for stability and performance. The storage layer handles data more efficiently now.
One standout: planner statistics now persist through major upgrades. Upgraded clusters reach peak performance faster, without waiting for ANALYZE to run on every table.
The backend also manages memory and processes queries more smoothly. These updates keep the database reliable under heavy load.
Storage tweaks reduce overhead for common operations. Both reads and writes see gains, no matter the workload.
Autovacuum Process Changes
The autovacuum system gets smarter in PostgreSQL 18. Maintenance operations run more effectively, so performance stays steady over time.
Autovacuum now times table maintenance better and uses resources more wisely. The process adapts to database activity patterns on the fly.
Improvements:
- Smarter vacuum scheduling
- Better resource allocation
- Less impact on active queries
These enhancements help prevent performance drops from bloated tables. The updated process works hand-in-hand with the new I/O system.
Even databases with heavy write activity or frequent changes keep consistent query performance.
SQL Features and Syntax Advancements
PostgreSQL 18 introduces virtual generated columns, temporal constraints for time-based data validation, and expands the RETURNING clause to more SQL operations.
VIRTUAL Generated Columns
With PostgreSQL 18, you can use virtual generated columns. These columns calculate values on-the-fly, not on disk.
Virtual columns save storage compared to stored generated columns. They calculate values during queries using expressions from other columns in the same table.
CREATE TABLE products (
id SERIAL PRIMARY KEY,
price DECIMAL(10,2),
tax_rate DECIMAL(4,3),
total_price DECIMAL(10,2) GENERATED ALWAYS AS (price * (1 + tax_rate)) VIRTUAL
);The engine evaluates virtual columns when you query the data. This is great for calculations that change a lot or when you want to save space.
You can’t index virtual columns directly, but you can create functional indexes on the expression itself.
Temporal Constraints and Indexing
PostgreSQL 18 makes handling temporal data easier with better constraint validation. Now you can add time-based constraints that prevent overlapping periods.
Set up constraints to ensure date ranges don’t conflict. This is handy for schedules, reservations, or anything time-sensitive.
CREATE TABLE bookings (
room_id INTEGER,
start_date DATE,
end_date DATE,
EXCLUDE USING gist (room_id WITH =, daterange(start_date, end_date) WITH &&)
);The new temporal indexing speeds up queries on date ranges. Filtering by time periods gets a noticeable performance boost.
These constraints kick in automatically during INSERT and UPDATE. The database stops any data that violates the temporal rules.
RETURNING Clause Enhancements
PostgreSQL 18 expands the RETURNING clause to more SQL statements. Now you can get data back from more than just INSERT, UPDATE, and DELETE.
The RETURNING clause works with MERGE statements. You can see which rows got inserted, updated, or deleted during merges.
MERGE INTO inventory t
USING new_stock s ON t.product_id = s.product_id
WHEN MATCHED THEN UPDATE SET quantity = t.quantity + s.quantity
WHEN NOT MATCHED THEN INSERT VALUES (s.product_id, s.quantity)
RETURNING t.product_id, t.quantity, 'merged' as action;CREATE DATABASE and CREATE ROLE now offer more output options too. You can grab more details about new objects right away.
With these changes, developers can cut down on round trips by getting results straight from modification statements.
Performance and Query Optimization
PostgreSQL 18 brings big improvements to query processing. Enhanced planner algorithms and better monitoring tools make a real difference.
The database now strips out unnecessary query operations automatically. It also gives you more detailed insights into system resource usage.
Query Planner Innovations
The PostgreSQL 18 query planner packs in advanced optimization techniques. These help the engine pick smarter ways to execute queries.
The planner uses improved algorithms to find better execution paths. Complex queries get analyzed and optimized, often without any manual tuning.
Key planner improvements:
- Smarter join ordering for multi-table queries
- Better cost estimation for query operations
- Improved parallel query planning
- More accurate use of statistics for optimization
The optimizer now handles bigger and more complex queries. It taps into available indexes and memory more effectively.
All of this often means faster queries, and most users will see the benefits without tweaking a thing.
Self-Join Elimination
Let’s talk about one of the bigger changes: automatic self-join elimination. Now, the planner can spot when a table joins to itself for no good reason and just skip those extra steps.
Self-joins crop up when a query uses the same table more than once. They can really drag down performance if you don’t catch them.
Common scenarios where self-join elimination helps:
- Subqueries referencing the same table as the main query
- Complex WHERE clauses with several conditions on a single table
- Views with pointless repeated table references
The planner looks at how your query’s put together, then cuts out any duplicate table scans. This means less data to chew through.
Some queries see a huge speed boost from this—sometimes several times faster than before.
EXPLAIN and EXPLAIN ANALYZE Improvements
PostgreSQL 18 steps up its EXPLAIN and EXPLAIN ANALYZE commands with richer performance details. These tools give database admins a sharper look at what’s actually happening behind the scenes.
EXPLAIN now shows off extra details about execution plans. You get more insight into how the planner chooses its path.
New EXPLAIN features include:
- More timing info for each operation
- Cleaner formatting for gnarlier plans
- Extra stats about how data gets handled
EXPLAIN ANALYZE spits out even better runtime stats. You can see real execution times and how much muscle each part of the query needs.
It’s just easier to spot what’s slowing things down. Admins can target the slowest bits and tune them up.
Buffer and WAL Usage Reporting
With PostgreSQL 18, you get deeper reporting for buffer cache and Write-Ahead Logging (WAL) usage. These new metrics give admins a clearer sense of where the system spends its resources.
Buffer usage stats reveal how queries hit PostgreSQL’s memory cache. This helps flag queries that hog memory.
New reporting metrics include:
- Buffer hit ratios per query
- WAL generated per operation
- Memory usage trends for different query styles
WAL usage reporting tracks how much transaction log data each query creates. If you see high WAL numbers, that usually means a query’s making a ton of changes.
You’ll find these numbers in EXPLAIN ANALYZE output and system monitoring views. Admins can use them to fine-tune performance and manage resources smarter.
System Catalog and Internal Changes
PostgreSQL 18 brings a handful of upgrades to system catalog tables and internal functions. Memory context handling’s leaner, and access control functions get a boost for tighter security.
Catalog Table Modifications
Several core system catalog tables get an update this time around. The pg_class table now deals with virtual generated columns more gracefully.
The database tracks column metadata with sharper precision. The catalog keeps extra info about how columns get generated.
Admins should see snappier performance when they poke around table metadata. Catalog tweaks also trim down storage for temporary table details.
pg_attribute now tracks generated columns better. It clearly separates stored versus virtual generated columns, which is handy.
All these changes keep things compatible with old setups. Tools that rely on system catalogs won’t need any updates.
System Functions and Roles
The pg_get_acl() function gets smarter in PostgreSQL 18. It now returns richer access control details for your database objects.
Role management’s smoother thanks to pg_authid improvements. The system catalog tracks more role attributes, which helps with security.
New system functions let admins check role permissions faster. Cleaner output formats make access control lists easier to read.
There’s also better support for temporal constraints in roles. You can set time-based access restrictions for users now, which is pretty useful.
Function performance’s up, too, since catalog lookups are speedier. Permission checks during queries put less strain on the system.
System Attribute Enhancements
PostgreSQL 18 brings in the pg_backend_memory_contexts view for easier memory monitoring. This new system view lays out detailed info about memory usage across different database processes.
Memory context tracking gets more granular in this release. Now, database administrators can spot memory leaks and find optimization opportunities with less hassle.
The system actually provides real-time memory stats for each backend process. That kind of detail helps a lot with troubleshooting performance hiccups or planning resources.
Temporary table handling feels smoother thanks to better memory context management. The database cuts down on memory overhead when you’re creating and dropping temporary objects all the time.
System attribute caching also sees some optimization, which helps reduce catalog bloat. Apps that churn through lots of temporary tables during operation will probably notice the difference.
