PostgreSQL 18 is officially released and this version brings some major improvements for performance and core database behavior.If you are running PostgreSQL in production, especially on cloud storage, this release is worth paying attention to.
In PostgreSQL 18, many improvements happen inside the database engine.That means you do not need to rewrite SQL queries or change application code to see the benefits. After upgrade, you can notice faster reads, better query plans, improved insert performance, and smoother upgrades.
In this blog, we will focus on the key PostgreSQL 18 changes that DBAs should not miss, including Asynchronous I/O, Index Skip Scan UUIDv7 and better observability.
Why PostgreSQL 18 Matters Now
The way we use databases today is very different compared to a few years ago.
More and more PostgreSQL systems are running in the cloud, and workloads are becoming heavier and more complex.
Today, most production environments deal with:
- larger data volumes
- higher concurrency
- more analytics and reporting workloads
- cloud storage latency and I/O limits
- distributed and always-on systems
Because of this, performance bottlenecks are no longer only about CPU or query design. A lot of performance issues come from storage behavior, inefficient scans, and internal engine limitations.
PostgreSQL 18 directly targets these modern challenges.It improves how PostgreSQL reads data from storage, how it chooses query plans, and how it handles internal operations like vacuum and WAL processing.
The best part is that many of these improvements work automatically. So after upgrading, you can see real performance benefits without rewriting SQL queries or changing application code.
Asynchronous I/O
Asynchronous I/O (Async I/O) is a new storage feature in PostgreSQL 18 that improves how PostgreSQL reads data from disk. With Async I/O, PostgreSQL can issue multiple read requests concurrently instead of waiting for each request to complete before sending the next one.
This reduces I/O waiting time and increases throughput, especially on SSDs and cloud storage where parallel requests perform better.
What Was the Problem Before PostgreSQL 18
Before PostgreSQL 18, PostgreSQL mainly used a sequential I/O approach:
- It sent one read request to storage
- Then it waited until the storage responded
- Only after that, it sent the next request
So even if the CPU was available, the database often slowed down because it spent a lot of time waiting for disk reads.
This became a bigger issue in cloud environments where storage latency is higher.
Async I/O in Action
Below is a simple example that shows the difference.
Async I/O Comparison
The table below shows a clear comparison between PostgreSQL 17 and PostgreSQL 18 using the same query and dataset.
| Comparison Aspect | PostgreSQL 17 | PostgreSQL 18 |
|---|---|---|
| I/O Method | Not available (sync by default) | io_method = worker |
| Parallel Workers | Not used | 4 workers planned and launched |
| Scan Type | Seq Scan on large_orders | Parallel Seq Scan on large_orders |
| Execution Time | 152346.102 ms (~2.5 minutes) | 51235.002 ms (< 1 minute) |
| Key Improvement | Query waits on disk reads | Multiple reads happen in parallel |
PostgreSQL 18 reduced execution time from 152 seconds to 51 seconds, giving roughly a 3× improvement for the same query and same dataset.
Index Skip Scan
Index Skip Scan is a new planner capability in PostgreSQL 18 that helps PostgreSQL use multicolumn indexes in more situations.Instead of scanning a full table, PostgreSQL can scan only the useful parts of an index by skipping over values it does not need.
This is especially helpful when the query does not filter on the first column of a multicolumn index, but still needs data from the later columns.
In older PostgreSQL versions, multicolumn indexes worked well only when queries matched the beginning of the index columns.If the query missed the first column condition, PostgreSQL often could not use that index efficiently.
So even with a good index available, the planner frequently chose a sequential scan and ended up reading a large portion of the table.This increased CPU and I/O usage and slowed down query execution on large datasets.
Query Optimization in Action: Before vs After
These screenshots compare the same query on PostgreSQL 17 and PostgreSQL 18.
In PostgreSQL 17, the planner uses a sequential scan, so it reads a large part of the table and removes many rows using the filter.
In PostgreSQL 18, the planner uses Index Skip Scan, which directly jumps through the index and reads only the required rows.
Final Result: Execution time reduced from 8925.778 ms to 5214.002 ms, giving about 40% faster performance without changing the SQL query.
Data Type & Core Enhancements
PostgreSQL 18 introduces several improvements in data types and internal engine behavior.
One of the most important and practical changes is the introduction of UUIDv7, which improves UUID indexing and write performance.
UUIDs are very common in modern applications, especially in microservices and distributed systems.
However, older UUID formats created hidden performance problems, especially on large insert-heavy tables.
Before PostgreSQL 18, most applications used UUIDv4, which generates random values.
Because UUIDv4 inserts values at random index positions, PostgreSQL constantly splits index pages and creates fragmentation.
Over time, this causes:
- Index bloat (indexes grow bigger than necessary)
- More page splits and extra disk I/O
- Higher WAL generation
- Slower inserts on large tables
This problem becomes serious in systems with heavy inserts, high concurrency, or large indexes.
UUIDv7
UUIDv7 is a time-ordered UUID format introduced in PostgreSQL 18 using the uuidv7() function.
Unlike UUIDv4, which generates random values, UUIDv7 generates values that follow time order.
This time-ordering helps PostgreSQL write data more efficiently and keeps indexes more organized over time.
UUIDv7 in Action
- In PostgreSQL 17,
gen_random_uuid()creates UUIDv4, which is fully random and inserts values in random index positions. - In PostgreSQL 18,
uuidv7()creates UUIDv7, which is time-ordered, so new values are inserted in sequence and indexes stay more organized.
Final Thoughts
PostgreSQL 18 brings major performance and core improvements, but the actual gain will not be the same for every application.Every environment is different like data size, query patterns, workload type, storage latency, and configuration settings all play a role.
So the best approach is to test each feature in your own staging setup, run your real workloads, compare the performance, and then tune based on what your system needs.
PostgreSQL 18 gives powerful new capabilities, but the real benefit comes when we apply them correctly based on our application and infrastructure.