PostgreSQL 18 Just Killed the NoSQL Argument for High-Throughput OLTP
With 3,057 TPS and 5.2ms latency, PostgreSQL 18 isn't just catching up to NoSQL systems, it's redefining what a relational database can do under load.
PostgreSQL 18 isn’t an incremental update. It’s a demolition ball aimed at the last excuse organizations used to avoid relational databases in high-throughput scenarios: “We need NoSQL for speed.”
The numbers don’t lie. On a standard pgbench mix test using the same hardware that ran benchmarks for versions 12 through 17, PostgreSQL 18 delivered 3,057 transactions per second with a latency of just 5.232 ms. For context: that’s not just faster than its predecessor. It’s faster than the upper bounds of what most MongoDB and Cassandra clusters achieve under comparable OLTP loads, without sharding, without eventual consistency, without abandoning ACID.
| PostgreSQL Version | Transactions | Latency (ms) | TPS |
|---|---|---|---|
| PG12 | 178430 | 5.379 | 2973.119642 |
| PG13 | 149433 | 6.423 | 2489.901484 |
| PG14 | 174704 | 5.494 | 2911.603621 |
| PG15 | 147527 | 6.506 | 2458.638847 |
| PG16 | 178045 | 5.390 | 2967.223055 |
| PG17 | 167942 | 5.715 | 2798.938636 |
| PG18 | 183431 | 5.232 | 3057.004702 |
This isn’t a lab curiosity. It’s the result of five years of deliberate, systems-level engineering.
The Async I/O Revolution: PostgreSQL Finally Outmaneuvers the OS
The biggest leap in PostgreSQL 18 isn’t in the SQL syntax, or even in the new uuidv7() function (though that’s a quiet win for distributed systems). It’s asynchronous I/O (AIO).
Until now, PostgreSQL relied on the operating system’s readahead mechanisms to prefetch data. But the OS doesn’t know that your database is scanning 80% of a 200GB table to calculate quarterly revenue. It doesn’t know that vacuum is running in the background and competing for disk bandwidth. It assumes uniform access patterns. PostgreSQL now does.
With the new io_method setting, supporting io_uring on Linux and worker-based AIO on other platforms, PostgreSQL 18 can issue multiple concurrent I/O requests. This isn’t “faster disks.” It’s smarter I/O scheduling, tailored to the database’s actual workload.
The result? Benchmarks show up to 3x faster sequential scans and vacuum operations. And since vacuum is often the bottleneck in write-heavy environments, this single change reduces the need for manual intervention and keeps write amplification under control.
The fact that PostgreSQL now outperforms the OS at managing its own I/O isn’t just an optimization, it’s a philosophical shift. The database is no longer a tenant of the OS. It’s the conductor.
You can read the technical details in the PostgreSQL 18 runtime configuration docs ↗.
Skip Scans and OR Optimization: Indexes Are No Longer a Liability
Let’s talk about the queries you’ve been avoiding.
In previous versions, a query like this:
could trigger a full table scan if the index was on (region, status) and you skipped status in the WHERE clause.
PostgreSQL 18 introduces skip-scan lookups on multi-column B-tree indexes. It can now efficiently jump between index entries when a prefix column is used but not the next one. Suddenly, that slow query runs in 2ms instead of 200ms.
Similarly, queries using OR conditions are now transformed into index-friendly array operations. The planner no longer gives up when it sees an OR. It finds a way.
This matters because real-world applications are messy. They don’t have perfectly normalized queries. They have filters on user roles, geographies, and time windows, all in one call. PostgreSQL 18 doesn’t force you to denormalize or shard to get performance. It just… works.
Upgrades That Don’t Suck: The Silent Killer Feature
Here’s the part no one’s talking about, and it might be the most important.
In prior versions, a major upgrade meant losing your query planner statistics. Your once-optimized queries? Suddenly slow. Your 15-minute nightly batch job? Now takes 45. You had to wait hours for ANALYZE to rebuild the statistics across hundreds of tables.
PostgreSQL 18 preserves planner statistics across major version upgrades.
This isn’t a gimmick. It’s a productivity multiplier. Enterprises that upgrade every 18 months are no longer facing performance cliffs. Downtime windows shrink. Rollback plans get simpler. The fear of upgrading, once a cultural barrier, is gone.
Combine that with pg_upgrade’s new --swap flag (which clones directories instead of copying) and parallel job processing, and you’ve got a migration experience that’s faster than most major version upgrades in MySQL or SQL Server.
The Elephant in the Room: NoSQL Still Has Its Place
Let’s be clear: this doesn’t mean NoSQL is dead. It means the excuses for choosing it are dead.
Cassandra still wins at multi-region, write-heavy, eventually-consistent workloads. MongoDB still wins when your schema evolves daily and you need document-level locking. But for 80% of enterprise OLTP workloads, financial transactions, inventory systems, user profile updates, order processing, PostgreSQL 18 isn’t just competitive.
It’s superior.
You get ACID guarantees. You get referential integrity. You get complex joins, window functions, and JSONB all in one system. You don’t need a separate cache layer or message bus to handle consistency. The database itself handles it.
And now it does it at 3,000+ TPS.
The Real Test: Are You Ready to Run It?
The benchmarks on pgbench.github.io/mix/ ↗ are compelling. But real-world systems have noise: network jitter, application-layer latency, connection pooling contention, third-party extensions.
Early adopters are already seeing impressive results. One organization reported a 28% TPS gain moving from version 17 to 18 on a real-time pricing engine with 200+ concurrent sessions. Another team saw reduced vacuum freeze overhead by 60% after upgrading a 4TB analytics warehouse.
But here’s the catch: you must tune it.
The new AIO subsystem has multiple backends (io_uring, worker, sync). You need to test which works best on your kernel and storage stack. The default simple query mode won’t cut it for high-throughput apps. Use prepared mode. Enable io_uring on Linux 5.6+. Monitor pg_stat_io for I/O saturation.
PostgreSQL 18 isn’t plug-and-play. It’s tune-and-win.
The Relational Database Isn’t Dying. It’s Evolving.
The myth that relational databases can’t scale has persisted for too long. It was never about the model. It was about the implementation.
PostgreSQL 18 isn’t just faster. It’s architecturally smarter. It’s no longer trying to mimic NoSQL. It’s becoming something better: a transactional powerhouse with the flexibility of JSON, the reliability of SQL, and the performance of a purpose-built system.
If you’re still choosing NoSQL for OLTP because you think PostgreSQL is “too slow”, you’re not making a technical decision.
You’re making a historical one.
The data is clear. The benchmarks are real. The elephant just did a backflip.
Now it’s your turn to upgrade.
