--- title: Rebuilding Postgres for 300x faster analytics: batching,... description: pgrust 0.2 achieves 300x faster analytical query performance than Postgres on ClickBench, even outperforming ClickHouse. The post walks through three key query... canonical: https://daily.dev/posts/rebuilding-postgres-for-300x-faster-analytics-batching-operator-fusion-and-simd-tgtpnmlyi twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Rebuilding Postgres for 300x faster analytics: batching, operator fusion, and SIMD | daily.dev og:description: pgrust 0.2 achieves 300x faster analytical query performance than Postgres on ClickBench, even outperforming ClickHouse. The post walks through three key query... og:url: https://daily.dev/posts/rebuilding-postgres-for-300x-faster-analytics-batching-operator-fusion-and-simd-tgtpnmlyi og:image: https://api.daily.dev/og/posts/TGtPnmLYi.png og:image:alt: Rebuilding Postgres for 300x faster analytics: batching, operator fusion, and SIMD og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Rebuilding Postgres for 300x faster analytics: batching, operator fusion, and SIMD **[Hacker News](https://daily.dev/sources/hn)** · 11 min read · 0 upvotes · 0 comments ## Summary pgrust 0.2 achieves 300x faster analytical query performance than Postgres on ClickBench, even outperforming ClickHouse. The post walks through three key query engine optimizations using Rust code examples: (1) batching — replacing row-at-a-time Volcano model calls with 1024-element batches, cutting time from 1.3s to 480ms; (2) operator fusion — combining sequential scan and aggregation into a single node to eliminate copy overhead, reaching 358ms; and (3) SIMD — using ARM NEON intrinsics to process 8 floats per iteration, reaching 135ms. Together these yield ~10x improvement in the query engine alone, contributing to the overall 300x gain. JIT compilation, which enables operator fusion for arbitrary queries, is teased as a future topic. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why is the Postgres Volcano-model query engine slower than a raw loop for aggregation queries? The Volcano model processes one row at a time through a next() call on every plan node, which prevents CPU pipelining and adds per-row function call overhead. In a benchmark summing 500 million float8 values, a miniature Volcano-style implementation took 1.3 seconds versus 358ms for an equivalent raw Rust for loop, before any further optimization. _Developers optimizing query engines can track deep dives like this on daily.dev to compare execution model trade-offs._ ### How much faster does batching rows make a Volcano-style query executor? Batching rows in groups of 1024 instead of one at a time cut execution time for a 500-million-row sum from 1.3 seconds to about 480 milliseconds, roughly 2.7x faster. The batch buffer is allocated on the stack so no memory allocation happens during execution, since allocation is a relatively slow operation in hot query paths. _Anyone tuning database internals can follow analytics performance techniques like batching on daily.dev._ ### How much speedup does SIMD add on top of operator fusion for a sum aggregation query in Rust? Using ARM NEON SIMD intrinsics to sum four lanes of doubles in parallel brought the 500-million-row sum down to 135ms, about 2.6x faster than the 358ms operator-fusion version and nearly 10x faster than the original Volcano-model implementation. This made the SIMD version almost 3x faster than a plain Rust for loop over the same data. _Engineers evaluating low-level performance tricks for analytical workloads can dig into comparisons like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 99 comments across hackernews (as of 2026-09-14). **TL;DR:** The community is genuinely impressed by the technical depth of the batching/SIMD optimizations and the ClickBench numbers, but is sharply divided over the AGPL license choice, the heavy use of AI (Claude) to generate the codebase, and whether the benchmark comparisons are fully fair. **Sentiment:** 30% positive · 40% mixed · 30% skeptical **The case for** - The formal verification and differential fuzz testing approach — uncovering ~100 bugs in pgrust and ~20 in Postgres itself — is seen as a credible correctness story. - The ClickBench results were independently spot-checked by an external reviewer who confirmed the speedup. - Adaptive query planning and work-stealing scheduler are highlighted as long-overdue improvements over vanilla Postgres. - The 'test mode' feature bringing template DB cloning under 10ms is called out as practically useful for test suites. **The pushback** - AGPL is considered a dealbreaker in most corporate environments, seen as misaligned with the project's apparent target audience of large analytics users. - The codebase was largely generated by Claude, raising concerns about hidden bugs, performance regressions, and whether it constitutes a legitimate derived work of Postgres that should carry the original license. - The headline 300x benchmark disables Postgres parallelism in the blog post's toy example, which commenters flagged as misleading before the author clarified. - The benchmark only reflects workloads where the entire dataset fits in memory, limiting real-world applicability claims. - Trust and longevity concerns: commenters argue that no matter the performance, enterprises won't migrate away from the established Postgres ecosystem to a one-person AI-generated project. **By community** - hackernews (mixed): Technically curious and engaged — the author's direct participation helped clarify several concerns — but deeply split on the AGPL license, AI authorship legitimacy, and benchmark fairness. **Hottest debate:** Whether using Claude to rewrite Postgres and then licensing the result under AGPL (rather than Postgres's permissive license) is legally and ethically valid, or constitutes an undisclosed derived work. **Open questions** - Will pgrust pursue a CLA process to safely accept outside contributions under a dual-license model? - How does pgrust perform on workloads that don't fit entirely in memory, where disk I/O dominates? - Could pgrust be embedded as a library (SQLite-style) given its pure-Rust implementation? - What is the detailed architecture of the I/O and thread scheduler, and how does it handle noisy-neighbor problems? - Does AI-generated systems code carry sufficient legal copyright protection to enforce the AGPL? **Highlights** > Author here. Let me know if you have any questions! Let me take a shot at answering what I think will be the most common question: how can I trust pgrust? Our #1 priority right now is correctness. Over the past two weeks, I've done a mix of formal verification and differential fuzz testing. We've been able to prove over 1000 user facing functions have the exact same logic in both pgrust and postgres (see the proofs directory if you're curious). For cases where formal verification is not easy, we've taken the c implementation of a function and the rust implementation of a function and ran millions of inputs through each of them and confirmed they gave the same results every time. We've only covered about 15% of the surface area so far, but in the process, we've discovered ~100 bugs in pgrust and ~20 bugs in Postgres itself. My favorite postgres bug we found is this one[0]. Postgres has a quadtree implementation. Due to floating point rounding, it was possible for a point to be neither above, nor below, nor even with the center point of the quadtree. We've also entered engagements with Antithesis[1] to do Jepsen style fault testing and Aretta[2] to do more serious formal verification. If you want to support the project, the easiest way is to give us a star on GitHub[3] [0] https://www.postgresql.org/message-id/19597-39c532e61d78dff6... [1] https://antithesis.com/ [2] https://aretta.ai/ [3] https://github.com/malisper/pgrust > — [malisper on hackernews · 7 comments](https://news.ycombinator.com/item?id=49212080) > Author here. At least for databases, AGPL (or stricter) has become standard. The issue is it's so easy for megacorps (Amazon, Google, etc) to take a permissively licensed product and monetize it at the expense of the original standard. For instance, Mongo, Cockroach, and Materialize have all gone source available. We picked AGPL because it's the best balance between open source and prevents Amazon from just repackaging it and selling it. If AGPL is an issue for anyone, we would be happy to dual-license under a commercial license. > — [malisper on hackernews · 3 comments](https://news.ycombinator.com/item?id=49211959) > They disabled Postgres parallelism to benchmark too. Sigh. > — [refulgentis on hackernews · 1 comments](https://news.ycombinator.com/item?id=49214570) > The project has 2 commits. 2. Commit #1's message is "hey claude, do a breakthrough" from a week ago. Commit #2 is "blog post" from 4 days ago. My head is spinning. I don't mind AI stuff or AI enabled stuff but there's gotta be some bar for ending up on HN, and also personal accountability: the lack of humility and honesty sets a new low for me. There is no "we" who "released pgrust 0.2". It's one person cosplaying a serious engineering team doing a mountain of work. ex. the first 1/3 of the blog post is bloviating about how a rust for loop is faster at summing 500M numbers on the heap than loading the numbers from a table and summing them. It leaves me in quite some anguish. This site kept me well-informed and growing for 16 years. It is no longer reliable for that as long as things like this can be the #1 post with 60 comments, with the author here, and no one mentioned any of this. > — [refulgentis on hackernews · 1 comments](https://news.ycombinator.com/item?id=49213943) > The pgrust team asked me to look at their results on a review system, and I confirmed the ClickBench speedup there. Regular PostgreSQL is really terrible at some of these queries. Unfortunately fixing that is hard to do in core itself because columnar storage lives outside of the main tree, and some optimization problems only show up when layered on columnar. > — [postgresperf on hackernews](https://news.ycombinator.com/item?id=49216239) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49208535) · 215 points · 99 comments - [hackernews](https://news.ycombinator.com/item?id=49155955) · 3 points · 0 comments ## Similar posts on daily.dev - [pg\_clickhouse is the fastest Postgres extension on ClickBench](https://daily.dev/posts/pg-clickhouse-is-the-fastest-postgres-extension-on-clickbench-kslwk5lud) · ClickHouse · 4 upvotes · 0 comments --- Tags: [#rust](https://daily.dev/tags/rust), [#postgresql](https://daily.dev/tags/postgresql), [#olap](https://daily.dev/tags/olap) [View this post on daily.dev](https://daily.dev/posts/rebuilding-postgres-for-300x-faster-analytics-batching-operator-fusion-and-simd-tgtpnmlyi) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Rebuilding Postgres for 300x faster analytics: batching, operator fusion, and SIMD","url":"https://daily.dev/posts/rebuilding-postgres-for-300x-faster-analytics-batching-operator-fusion-and-simd-tgtpnmlyi","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/rebuilding-postgres-for-300x-faster-analytics-batching-operator-fusion-and-simd-tgtpnmlyi"},"datePublished":"2026-08-07T16:00:17.026Z","dateModified":"2026-09-14T08:48:35.560Z","description":"pgrust 0.2 achieves 300x faster analytical query performance than Postgres on ClickBench, even outperforming ClickHouse. The post walks through three key query...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/2cb93807565696f7fd386e393cf2a13c?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/2cb93807565696f7fd386e393cf2a13c?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/rebuilding-postgres-for-300x-faster-analytics-batching-operator-fusion-and-simd-tgtpnmlyi","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"rust,postgresql,olap","timeRequired":"PT11M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"Rebuilding Postgres for 300x faster analytics: batching, operator fusion, and SIMD"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/rebuilding-postgres-for-300x-faster-analytics-batching-operator-fusion-and-simd-tgtpnmlyi#faq","mainEntity":[{"@type":"Question","name":"Why is the Postgres Volcano-model query engine slower than a raw loop for aggregation queries?","acceptedAnswer":{"@type":"Answer","text":"The Volcano model processes one row at a time through a next() call on every plan node, which prevents CPU pipelining and adds per-row function call overhead. In a benchmark summing 500 million float8 values, a miniature Volcano-style implementation took 1.3 seconds versus 358ms for an equivalent raw Rust for loop, before any further optimization. Developers optimizing query engines can track deep dives like this on daily.dev to compare execution model trade-offs."}},{"@type":"Question","name":"How much faster does batching rows make a Volcano-style query executor?","acceptedAnswer":{"@type":"Answer","text":"Batching rows in groups of 1024 instead of one at a time cut execution time for a 500-million-row sum from 1.3 seconds to about 480 milliseconds, roughly 2.7x faster. The batch buffer is allocated on the stack so no memory allocation happens during execution, since allocation is a relatively slow operation in hot query paths. Anyone tuning database internals can follow analytics performance techniques like batching on daily.dev."}},{"@type":"Question","name":"How much speedup does SIMD add on top of operator fusion for a sum aggregation query in Rust?","acceptedAnswer":{"@type":"Answer","text":"Using ARM NEON SIMD intrinsics to sum four lanes of doubles in parallel brought the 500-million-row sum down to 135ms, about 2.6x faster than the 358ms operator-fusion version and nearly 10x faster than the original Volcano-model implementation. This made the SIMD version almost 3x faster than a plain Rust for loop over the same data. Engineers evaluating low-level performance tricks for analytical workloads can dig into comparisons like this on daily.dev."}}]} ```