Glonce

pgrust v0.2 claims 300x Postgres speed on analytics

infrastructureThe Glonce editorsHacker News🔥68Glonce rating68Impact65Novelty60Relevance72Surprise58Players30Credibility76
pgrust v0.2 claims 300x Postgres speed on analytics

The team behind pgrust released version 0.2 of the database last week, a release the post describes as "all about performance." Against the previous pgrust release, v0.2 is 10x faster. Against Postgres, it is 30% faster on OLTP benchmarks and 300x faster on Clickbench, ClickHouse's benchmark for analytical databases; the team says pgrust now beats ClickHouse itself on that benchmark. Roughly 10x of that 300x Clickbench gain, the post says, comes from the query engine alone.

To show why the query engine matters, the post walks through one example: summing 500 million floating point numbers. Run in Postgres on an AWS c8g.4xlarge instance (Graviton4, 16 vCPU) with parallel queries disabled, the query takes about 20 seconds. The same sum written as a plain Rust for loop takes 358ms, about 55x faster; the author flags this as not an apples to apples comparison, since Postgres does far more work under the hood, naming locking and parsing its on-disk tuple format as two of the biggest sources of that overhead.

The post frames the gap historically: Postgres dates back to the 1980s, when disk I/O was the main bottleneck to database performance. Three shifts have changed that, per the post: many datasets now fit in RAM; workloads that don't fit in RAM tend to be bulk analytical scans bound by CPU or memory throughput rather than disk; and NVMe disks are hundreds of times faster than old hard drives. That makes the query engine, described as the main consumer of CPU in a database, the place to optimize. Postgres itself has over 40 distinct plan-node types and executes them with what the post calls the "Volcano model," where each node exposes a next() method that returns one row at a time.

The post then rebuilds a miniature version of that engine and adds optimizations one at a time. An unbatched, row-at-a-time Volcano-style implementation takes 1.3s to run the same 500-million-row sum, slower than the raw loop because per-row function calls defeat CPU pipelining. Adding batching, buffering 1,024 rows per call in a stack-allocated array with no heap allocation, cuts that to about 480ms. Profiling then shows the remaining cost is copying values into the batch buffer; "operator fusion," merging the scan and the sum into a single node, removes that copy and matches the raw loop's speed, though the post notes this hardcodes an optimization for one specific query shape and does not generalize on its own. Generalizing it, the post says, is what JIT compilation is for; pgrust reportedly uses JIT for this, but the post explicitly defers how to a future writeup. Finally, adding SIMD, using aarch64 vector intrinsics to sum four accumulator lanes at once, brings the time to 135ms, about 3x faster than the plain for loop and 10x faster than the original unbatched engine. The post adds that compilers usually skip auto-vectorizing float sums like this because floating-point addition is not associative, so reordering the additions via SIMD can change the result slightly.

Benchmark setup, as stated in the post: AWS c8g.4xlarge (Graviton4, 16 vCPU); PostgreSQL 18.4 with max_parallel_workers_per_gather set to 0 and data warm in shared buffers; Postgres timings are the median of 5 runs; the Rust implementations were built with cargo build --release and run 4 times each, all measured in one process on one machine. The post does not name which OLTP benchmark suite produced the 30% figure, does not give an absolute release date beyond "last week," and does not name an individual author, team, or company; it is written throughout in first person plural.

Key facts

  • pgrust v0.2 is 10x faster than the previous pgrust release, 30% faster than Postgres on OLTP benchmarks, and 300x faster than Postgres on Clickbench, ClickHouse's analytical benchmark, where it now claims to beat ClickHouse itself.
  • About 10x of that 300x Clickbench gain is attributed to the query engine alone.
  • In a 500-million-row sum benchmark on an AWS c8g.4xlarge instance, Postgres took about 20 seconds versus 358ms for a plain Rust for loop.
  • A miniature Volcano-style engine went from 1.3s (row at a time) to 480ms (batching 1,024 rows) to matching the raw loop (operator fusion) to 135ms with SIMD added on top, about 3x faster than the loop and 10x faster than the original.
  • JIT compilation, which the post says pgrust also uses to generalize operator fusion beyond hardcoded cases, is explicitly not covered or benchmarked in this post.

Why it matters

Postgres's architecture dates to the 1980s, when disk I/O was the dominant bottleneck. The post argues three shifts have moved the bottleneck elsewhere: datasets increasingly fit in RAM; the workloads that don't fit in RAM are bulk analytical scans bound by CPU or memory throughput rather than disk; and NVMe disks are far faster than the hard drives Postgres was designed around. That shifts the pressure onto the query engine, the component the post calls the main consumer of CPU in a database. pgrust's team rewrote that component to use less CPU and less memory bandwidth per query, and credits it with roughly 10x of pgrust's overall 300x edge over Postgres on Clickbench.

Who it affects

The post targets people running or evaluating Postgres for analytical (OLAP-style) workloads, where it claims the largest gain (300x on Clickbench versus 30% on OLTP). It names no specific adopters, companies, or users of pgrust; the claims are about the database's own benchmark results, not about deployments.

How to use it

Version 0.2 of pgrust is out, described in the post as a release focused entirely on performance. The post is framed as the first of a series: it covers batching, operator fusion, and SIMD, and explicitly defers a writeup on pgrust's use of JIT compilation to a future post. No pricing, licensing, or installation details appear in the source text.

How solid is it

The figures are self-reported by pgrust's own team on their own benchmark setup: an AWS c8g.4xlarge instance (Graviton4, 16 vCPU), PostgreSQL 18.4 with parallel workers per gather disabled and data warm in shared buffers, Postgres timings taken as the median of 5 runs, and the Rust code built with cargo build --release and run 4 times per implementation, all on one machine in one process. The post itself flags its headline for loop comparison as not apples to apples, since Postgres performs additional work (locking, parsing its storage format) that the raw Rust code skips entirely. No independent benchmark of pgrust is cited, and the OLTP suite behind the 30% figure is not named.

Risks and caveats

The 300x figure applies specifically to Clickbench-style analytical queries; the OLTP gain over Postgres is a much smaller 30%, and neither number has independent verification in the source. The operator fusion technique shown in the post is hardcoded to one specific query shape and, by the author's own admission, does not generalize without JIT compilation, which this post neither implements nor benchmarks. The article discloses no individual author, team, or company name, only first person plural throughout, and gives no absolute date for the v0.2 release, only "last week."

“The query engine is the main user of CPU in a database.”

— pgrust's developers, in the post