By ByteBot
This week, pgrust author Michael Malis published a technical deep-dive explaining exactly how his Rust reimplementation of PostgreSQL achieves 300x faster analytics on Clickbench — beating not just Postgres, but ClickHouse itself. The answer comes down to three compounding CPU-level optimizations: batching, operator fusion, and SIMD. The post is trending on Hacker News today, and it reveals precisely what Postgres’s 40-year-old query engine has been leaving on the table every time you run an analytical query.
The Volcano Model: Postgres’s 1980s Ceiling
PostgreSQL’s query engine runs on the Volcano model — every node in a query plan implements a single next() method that returns one row at a time. A sequential scan returns row 1, hands it to the aggregation node, then returns row 2, and so on. On a 500-million-row SUM() query, this costs 1.3 seconds in pure CPU overhead. Not I/O. Not network. CPU overhead from processing rows one at a time.
This design made sense in the 1980s. Disk I/O was the bottleneck; wasting CPU cycles on a row-at-a-time model wasn’t the concern. Today, larger datasets fit in RAM, NVMe storage is hundreds of times faster than spinning disks, and the bottleneck has shifted to CPU throughput and memory bandwidth. The Volcano model creates per-row function call overhead that prevents CPU pipelining. Modern processors want to execute many operations in parallel — and row-at-a-time processing fights that at every step.
Related: pgrust Hits 100%: The AI-Built Postgres Rewrite in Rust
Three Optimizations That Compound Into 300x
pgrust’s query engine deep-dive walks through three successive changes to the execution model. Malis shows minimal implementations of each, and the performance numbers at each step make the compounding nature visible.
Batching replaces next() — which returns a single row — with next_batch(), processing 1,024 rows at a time using stack-allocated buffers. This alone cuts the 500M row SUM() from 1.3 seconds to 480ms: a 2.7x improvement. The CPU can now pipeline operations across a block of rows instead of stalling at each individual function call boundary.
Operator fusion combines the sequential scan and aggregation into a single SumAggregateSequentialScan node, eliminating the intermediate buffer copy between operators. Performance drops to 358ms — 3.6x faster than the Volcano baseline. The tradeoff is generality: fused nodes are pattern-specific, which adds implementation complexity as query types grow.
SIMD finishes the job. Using four 128-bit accumulators operating on 8-element chunks — with special handling for row count remainders — the SUM() drops to 135ms. That is 9.6x faster than the Volcano baseline and nearly 3x faster than a naive for-loop. Single-instruction multiple-data lets the CPU process multiple values per cycle instead of one.
Across the full Clickbench analytical benchmark, these techniques compound to deliver 300x faster performance than PostgreSQL and 18.5% faster than ClickHouse. For OLTP workloads, pgrust runs 30% faster than Postgres on sysbench at 300GB scale. The benchmarks were independently reviewed by Greg Smith, a recognized PostgreSQL performance analyst.
| Optimization | Time (500M row SUM) | vs. Volcano |
|---|---|---|
| Volcano model (baseline) | 1.3s | 1x |
| + Batching (1,024 rows) | 480ms | 2.7x |
| + Operator Fusion | 358ms | 3.6x |
| + SIMD (8-element chunks) | 135ms | 9.6x |
What pgrust Actually Is Right Now
pgrust is not production software. The developers are explicit: “Do not put data you care about in it.” The project, led by Michael Malis (ex-Neon) and Jason Seibel, started in April 2026. It now passes all 46,066 queries in PostgreSQL 18.3’s regression suite, maintains wire and SQL dialect compatibility, and has 4,000 GitHub stars. Benchmarks were independently validated. It is, by any engineering measure, a serious technical achievement.
However, the extension ecosystem is essentially untested. pgvector, PostGIS, TimescaleDB, and PL/Python have not been validated against pgrust. Regression tests cover known bugs; production exposure finds the unknown ones. Ben Dicken, known for rigorous database benchmarking work, noted pgrust “doesn’t meet his bar quite yet.” The community split is predictable: those who think passing 46,000 tests is sufficient evidence that the architecture works, and those who think passing tests is the easy part. Both are right, depending on what you’re measuring. Check the pgrust GitHub repository for the latest status.
What This Means for the Postgres Ecosystem
The standard analytics architecture in 2026 runs Postgres for OLTP, pipes changes via CDC to ClickHouse or Snowflake for OLAP queries. It works. It is also two systems to maintain, two sets of credentials, two failure modes, and two billing accounts. pgrust raises a pointed question: is this split inherent to databases, or inherent to Postgres’s Volcano model specifically?
These three techniques — batching, operator fusion, SIMD — are not novel. DuckDB and ClickHouse have used vectorized execution for years. pgrust’s contribution is demonstrating that a full, wire-compatible Postgres reimplementation can use them too. Could these techniques be backported to Postgres itself? The honest answer is not easily. Postgres’s executor is deeply built around the one-row-at-a-time model. Projects like ParadeDB try analytics acceleration via extensions but fight the same architectural gravity. pgrust’s answer is to start from scratch.
Whether pgrust reaches production readiness in one year or five is secondary. What matters is that it empirically answers where Postgres’s analytics ceiling comes from — and the answer is the query engine, not the hardware.
Key Takeaways
- Postgres’s Volcano model processes one row per function call — a design from when disk I/O dominated. Modern hardware shifted the bottleneck to CPU throughput and memory bandwidth.
- pgrust achieves 300x faster analytics through three compounding optimizations: batching (2.7x), operator fusion (3.6x cumulative), and SIMD (9.6x on the query engine alone).
- The system benchmarks at 18.5% faster than ClickHouse on Clickbench and 30% faster than Postgres on OLTP — independently reviewed by Greg Smith.
- pgrust passes 100% of Postgres 18.3 regression tests but is not production-ready and lacks validated extension support (pgvector, PostGIS, TimescaleDB).
- The OLTP+OLAP two-system architecture is a pragmatic workaround to Postgres’s design, not an architectural necessity — pgrust makes that case concretely.
