pgrust v0.4-beta ships Gravity query engine, claims 3x ClickHouse speed on ClickBench

pgrust v0.4-beta introduces the Gravity query engine

The team behind pgrust, a Postgres-compatible analytical engine with columnar storage, has released v0.4-beta, introducing a new query engine called Gravity. According to the company's blog post, which surfaced on the front page of Hacker News, Gravity runs the ClickBench benchmark up to three times faster than ClickHouse — the very system that benchmark was created to showcase — while still supporting the complete Postgres SQL dialect and type system. The figures are the vendor's own rather than independently audited, but the engineering strategy behind them is direct: compile each SQL query into machine code at runtime.

From copy-and-patch to a real compiler

Gravity builds on work pgrust described in earlier posts: batching, operator fusion and SIMD pushed analytical queries to hundreds of times Postgres' speed, and a copy-and-patch JIT assembled pre-compiled stencils in five microseconds. The authors argue that gluing templates together hits a ceiling. Without a genuine intermediate representation and register allocation spanning a whole loop, generated code falls short of what an optimizing compiler such as rustc or Clang would produce. For v0.4 they set out to close that gap with a compiler that emits tailored machine code for any SQL query.

Establishing the speed limit with AI

Their approach inverted the usual optimization loop. Rather than profiling hotspots and shaving off 15 to 20 percent at a time, they tried to determine the fastest execution their hardware and file format physically allow, then work backwards — a method they call “programming at light speed.”

To measure that ceiling, they had Claude, the AI model, write standalone, heavily optimized Rust programs for a corpus of analytical queries. These bypassed the SQL executor entirely, running hand-written multithreaded loops with SIMD straight against pgrust's on-disk format. According to the post, those programs ran roughly four times faster than established analytical databases like ClickHouse, consistently across the query set. The team then mined them for optimizations and set Gravity a concrete target: for any SQL query, JIT-compile runtime code that lands within 20 percent of the hand-written reference.

Lowering SQL to assembly

Gravity keeps Postgres' parser and planner in place; the pgrust planner still consults table statistics and produces a standard query plan. A multi-stage compiler then lowers that plan step by step: to a pipeline graph describing how data flows, to a Lisp-based intermediate representation resembling assembly, and finally to assembly through per-target backends.

In the post's worked example — a grouped aggregation over a hits table with a LIKE filter, ordered by count and limited to ten rows — the pipeline graph splits execution into three pipelines. The first scans rows, applies the filter and builds a hash aggregate; the second pushes the results into a heap of ten for the top-k; the third projects the winning rows onto the wire.

Each pipeline compiles into a single function in the Lisp IR, which is what makes deep fusion possible: scan, filter, projection and aggregation collapse into one loop. The annotated IR shows what that buys. The URL filter becomes a single bit test because the column is dictionary-encoded; extracting the minute from a timestamp uses multiply-and-shift arithmetic instead of division; and the active group's keys stay in registers, with the hash table touched only when a row's keys don't match.

Why it matters

The launch is notable first for what it claims to dissolve: the usual trade-off between analytical speed and Postgres compatibility. Teams either keep Postgres and accept slow analytics, or move workloads to columnar stores like ClickHouse and give up Postgres SQL and its ecosystem. If pgrust's numbers survive independent testing, Gravity is evidence that ClickBench-class performance and the full Postgres dialect can coexist.

The methodology deserves attention on its own. Using an AI model to generate hand-tuned reference implementations, treating them as a measurable performance ceiling, and then asking a compiler to close the gap is a workflow other performance-focused projects could adopt — and it is a concrete example of AI-written code shaping a shipped system rather than a prototype.

The caveats are real, though: this is a 0.4 beta, the benchmark results are self-reported, and ClickBench comparisons have a long history of methodological dispute. Independent replication on standard hardware is the test that matters next.