A Rust-based Postgres rewrite called pgrust has been making the rounds, and its claim is hard to ignore: it runs analytical queries hundreds of times faster than stock Postgres. The author’s write-up walks through how, and the techniques are refreshingly concrete. This is not a vaporware benchmark grab, it is a working implementation that passes Postgres’s own regression tests and went through an independent analyst review.
The core problem it attacks
Standard Postgres uses the Volcano execution model. Every operator, a scan, a filter, an aggregation, hands rows one at a time to the next operator in the tree. That design made sense in the 1990s when the goal was flexibility and low memory use. But the per-row function call overhead is brutal on analytical queries that touch millions of rows, and it is a big reason why Postgres lags dedicated column stores like ClickHouse on reporting workloads.
pgrust flips that model. Instead of one row at a time, it processes rows in batches, up to 1,024 at once. The idea is not new, column databases have done this for years, but porting it into Postgres is what makes it notable.
Three techniques, one goal
The first is batching. Pulling a thousand rows through the pipeline instead of one cuts the per-row overhead by a factor of a thousand. The second is operator fusion. Sequential scans and aggregations get combined into a single node so data does not bounce between operators and through intermediate buffers. Fewer round trips through the executor means less wasted work.
The third is SIMD. Modern CPUs can process multiple values in a single instruction, and pgrust leans on that, handling several values per cycle instead of one. When you stack batching, fusion, and SIMD together, the throughput gains compound rather than add.
The numbers people are quoting
The headline is roughly 300x faster analytical performance than stock Postgres. Independent reviewer Greg Smith validated the results, which matters because benchmark claims in the database world are often cherry-picked. The project also reports being around 18% faster than ClickHouse on ClickBench, the standard analytical benchmark, and passing all of Postgres’s regression queries, which is a strong compatibility signal for a rewrite.
Let me be clear on what those numbers do and do not mean. The 300x figure targets analytical workloads that were the worst case for the old model. Transactional workloads, the row-by-row OLTP path, will not see anything like that because that was never the bottleneck. If you are comparing against ClickHouse, that is an apples-to-oranges fight on entirely different architectures, and one benchmark result should not be read as a general verdict.
Why the architecture choice matters
Writing it in Rust is not cosmetic. Rewriting the query engine in a low-level language with fine control over memory layout is precisely what lets the author do SIMD and batch processing without fighting a runtime. It is also a signal about where Postgres compatibility can go. Passing the full regression suite means applications and SQL written for Postgres should largely work, which is the hard part of any database rewrite and the reason most attempts fail.
The project is licensed AGPL, and the stated reason is deliberate: to keep companies from taking it, rebranding it, and closing it off. That is a real trade-off. It protects the project from corporate capture but also rules it out for some organizations and products whose licensing policies clash with AGPL. Worth knowing before you adopt it.
What this means in practice
For teams running Postgres for both transactions and reporting, the appealing scenario is collapsing two databases into one. If a Postgres-compatible engine can handle analytics fast enough, you avoid the operational cost of maintaining a separate ClickHouse or similar store, replicating data into it, and keeping schemas in sync. That is a genuinely attractive outcome for small-to-mid teams.
The honest caveat is maturity. This is young software, and the analytical path is the showcase. If you are going to try it, do it on a copy of your workload with your own queries and measure, do not trust the published benchmark as a guarantee for your data shapes. Watch the project for how quickly the OLTP path and operational edges get hardened.
How to evaluate it for your workload
If the idea appeals, run a structured test before committing. Take a representative slice of your analytical queries, the ones that currently crawl or that pushed you toward a separate store, and time them against both stock Postgres and pgrust on identical hardware. Pay attention to warm versus cold results, and to memory pressure, because batch processing trades memory for speed and your hosting may have limits.
Also check your licensing posture against AGPL before it becomes a blocker later. Verify your reporting queries survive the compatibility claim by running them unmodified, not just the regression suite. A rewrite can pass its own tests and still trip over an exotic clause your application relies on. Ten minutes of testing now beats a migration surprise later.
The bigger picture
pgrust is the latest evidence that the old OLTP-versus-OLAP split is dissolving. The technical path to one engine handling both is being walked in public, with Postgres compatibility as the anchor so nobody has to relearn SQL or migrate their data. Whether pgrust itself becomes the winner is an open question, but the direction it points is the interesting part. If a Postgres-compatible engine can credibly go 300x on analytics, the case for running a separate analytical database gets noticeably weaker.