pgrust's 5-microsecond compile drags JIT onto the short-query path

The break-even test is the part that moves. PostgreSQL keeps JIT in the analytics box because, by its own documentation, compilation overhead can exceed the time saved on short work ^[3]. At the roughly 50 milliseconds the pgrust repository attributes to the LLVM or generated-code route ^[5], that box is drawn tightly: compiling for a statement that would otherwise finish in a millisecond costs fifty times the statement ^[2]. At 5 microseconds the same compile is half a percent of it ^[2]. The repository's 10,000-fold figure checks out as arithmetic ^[1], but the useful reading is not the ratio, it is that the threshold falls below the runtime of nearly every query an OLTP system serves ^[11].

Copy-and-patch is what buys it. pgrust skips intermediate representation entirely and emits ARM64 instructions, starting from small machine-code templates called stencils and patching in characters, addresses and branch offsets at runtime before joining them, copying them into executable memory and calling the result as an ordinary function ^[4]. That design moves correctness out of a compiler and into the stencil library. There is no optimizer between intent and bytes, which is why the compile is fast, and also why the review burden is per stencil and per instruction set. pgrust 0.2 aims its JIT at ARM's Neoverse V2, the core in AWS Graviton4, and the repository says pgrust runs elsewhere without comparable performance ^[9]. Malis's argument for that narrowing is that database workloads land on a small set of cloud hardware, so portability is the thing worth trading ^[10].

The evidence sits at an awkward distance from the claim. The published execution numbers come from a deliberately limited regular-expression engine that supports literal strings, concatenation and `*` repetition, with no alternation, no lookbehind and no parser ^[6]. On that engine, Malis's own benchmark had generated code running 12 to 20 times faster than the interpreter and roughly matching handwritten code, and those are demonstration results rather than an independent database test ^[7]. Three regex constructs is a long way from SQL, and the 5-microsecond figure measures compilation, not execution ^[5].

Then there is who wrote the instructions. Malis says he had never written assembly before this, his prior exposure being a security challenge, and that a coding agent produced much of the instruction-level work once he had specified the compiler's structure ^[8]. That is the actual wager: he and Seibel started the rewrite around April 2026 on the view that agents make it affordable to revisit architectural choices a mature database cannot change without breaking installations ^[13]. Emission is plainly cheaper now. Verification of hand-shaped machine code, multiplied by every stencil and every target you eventually want, is the cost the wager has not yet priced, and it is the cost that grows if pgrust ever needs a second instruction set.

The funding line is consistent with an unpriced bill. Malis said on Postgres FM that he has paid for pgrust personally out of proceeds from selling some Freshpaint equity, that the spending was becoming hard to sustain, and that this prompted work on reducing token use ^[12]. He is not new to the problem space; per his Y Combinator profile he joined Heap out of high school in 2015 and led work on a roughly petabyte PostgreSQL cluster ^[14]. The engineering claim and the financing claim are being tested in the same repository.