Rewriting Postgres and Simplifying von Neumann · Morning Gist
Monday, October 262 stories · 7 min
Rewriting Postgres and Simplifying von Neumann
Two essays on ambition and abstraction: what to build now that code is cheap, and how a clean model can help an engineer or mislead one.
Picked from 60 new articles across 34 sources · arrow keys for other days
Today in 30 seconds
30s left
Dan Luu argues that cheap AI-written code means engineers should take on much bigger projects, such as pgrust, a Rust rewrite of Postgres. story 1 ↓
Testing pgrust turned up real bugs in Postgres itself. Luu's point is that the limit is now verification, not writing the code. story 1 ↓
Yossi Kreinin pushes back: most teams should aim lower, not reach for rewrites on the scale of Postgres. story 1 ↓
Murat Demirbas reviews Bhattacharya's von Neumann biography, which ties the stored-program computer and majority-vote fault tolerance to one habit of abstraction. story 2 ↓
The same habit led von Neumann to call for a nuclear first strike, a case of a clean model misleading him. story 2 ↓
1/2Dan Luu· Oct 24
Dan Luu: cheap code means engineers should attempt much bigger projects
Dan Luu says coding agents now make projects like a Postgres rewrite or a Rust interpreter practical. In his view, careful testing separates useful work from slop. Yossi Kreinin replies that most people should aim lower.
Why it matters · AI tooling is the backdrop. The argument underneath is about engineering practice: how cheaper code shifts build-versus-tolerate decisions, and why verification, not implementation, is now the limit.
Know this first
Context from the editor, not the article · 37 sec
1 · Postgres rewrites and pgrust
PostgreSQL is a widely used open-source relational database written in C. pgrust, led by Michael Malis, reimplements it in Rust. Rust is a memory-safe systems language. pgrust's main pitch is speed. Rewrite projects like this are common now and are often dismissed as low-quality AI output.
2 · Amdahl's law
If you speed up only part of a job, the parts you didn't touch cap the total gain. Make 10% of a task 1000x faster and the whole task gets barely 11% faster. This is why speeding up one step of a workflow rarely changes the overall time much.
3 · Property-based testing and fuzzing
Instead of hand-written example cases, you either state properties that must always hold and let a tool generate thousands of inputs to check them, or feed in random or mutated input to find crashes. Both turn correctness into a check a machine can run over and over.
2/2Murat Demirbas (Metadata)· Murat· Oct 26
Murat Demirbas on von Neumann: abstraction as a superpower and a trap
Distributed-systems researcher Murat Demirbas reviews a biography of John von Neumann. He argues that one habit sat behind most of von Neumann's breakthroughs: reducing a messy problem to its smallest working model. The same habit produced his worst judgments.
Why it matters · The ideas behind replication, quorums and the stored-program machine come from von Neumann, and his career is a case study in when a clean model helps and when it misleads.
Know this first
Context from the editor, not the article · 32 sec
1 · Who von Neumann was
John von Neumann (1903–1957) was a Hungarian-American mathematician. He worked at Princeton's Institute for Advanced Study and on the Manhattan Project at Los Alamos. He contributed to set theory, quantum mechanics, game theory, early computers and nuclear strategy.
2 · Who is reviewing
Murat Demirbas is a distributed-systems researcher who writes the Metadata blog, mostly about consensus protocols, databases and papers. This post reviews Ananyo Bhattacharya's 2021 biography of von Neumann. It is an essay about a way of thinking, not a technical paper.
Online analytical processing: large scan-and-aggregate queries, as opposed to many small transactional queries.
Dan Luu's new post builds on a line from his friend Michael Malis: "we should be more ambitious with the software we build." Luu would say "can." His argument is that coding agents have made large or highly specialized projects cheap to try, but most engineers still budget by a "pre-agentic cost model." He says he wrote the post quickly and didn't benchmark his own projects rigorously.
1 as the example
Malis leads pgrust, a reimplementation of PostgreSQL in Rust. Luu concedes that most rewrites like this are "vibeslop," generated code that never works. What sets pgrust apart for him is its testing, which has found real bugs in Postgres itself:
a numerical bug in 2 indexes
a 3 format-cache bug that returns wrong results
a pgcrypto bug
an overflow in the money type
So even if pgrust fails, Postgres has already improved. Luu also trusts Malis's honesty. Malis advises against running pgrust as a primary production database, and he says openly that the 0.4-beta query engine, tuned for analytical workloads, is slower than Postgres on very fast queries.
Removing bottlenecks
Luu asked what would slow him down if models ran 10–100x faster. His answers: 4 code search, Rust compilation, and filesystem overhead. In a few hours, with no compiler background, he built three things:
a regex engine that compiles patterns to native code
a ripgrep fork that uses it
a Rust interpreter that he says made cold builds about 50x faster and warm builds about 2x faster
He estimates this would have taken a year by hand. He also argues that toolchains could now bypass the Unix filesystem API and use 5.
Verification is the limit
Models improve fast. In Luu's informal tests, a current model passes all registered tests for a 6 compression implementation more than 99% of the time, for about $1. Yet he finds himself further from "it just works" with each generation, because what models can build is growing faster than what they can check. His answer is self-checking setups. For example, he ran automated consistency checks across a board game's contradictory rulebooks to produce a correct spec. He compares this to fuzzing and property-based testing, which in his experience work even in domains where people insist they won't. Amdahl's law, he says, means the big gains come from taking on work that used to be too expensive, not from redoing old work faster.
The pushback
Yossi Kreinin argues that most people should be less ambitious. Many problems lack clear pass/fail criteria. Black-box code is hard to reason about. Agent-written performance code is often overfit to the benchmark and hard to maintain. He compares it to microservices, which a few teams need and most misuse. Luu grants that bugs are everywhere now, but holds that other people shipping slop doesn't oblige you to.
Dan Luu has written a short, deliberately unpolished post around a line his friend Michael Malis keeps repeating: "we should be more ambitious with the software we build." Luu would put it as "can" rather than "should." His claim is that coding agents have made large or highly specialized projects cheap enough to try. He thinks engineers still budget by what he calls a "pre-agentic cost model," so they leave obvious wins untried. Luu says up front that he wrote the post in about half an hour and didn't benchmark his own projects rigorously. Read the numbers below as his informal measurements.
Exhibit A: 1 and the bugs it found in Postgres
pgrust is Malis's reimplementation of PostgreSQL in Rust. Luu admits that most rewrite projects like this are "vibeslop," meaning generated code that never works, and that skepticism is the sensible default. His evidence that pgrust is different is its testing. The tests have turned up real bugs in Postgres itself:
a numerical bug that can make valid 2 operations fail (SP-GiST is a Postgres index type for space-partitioned data)
a format-cache bug that can return incorrect results from 3 queries
a pgcrypto bug that can make later operations fail
several memory-safety problems in the dictionary loader (reviewer Alex Kolovsky points out that Postgres doesn't treat these as bugs)
an overflow in the money type
Luu's point is that even if pgrust fails, the attempt has already improved Postgres. Its performance work could also find its way into Postgres or ClickHouse, the analytical database.
He also vouches for how Malis talks about the project, which he contrasts with typical database marketing. Malis tells users not to run pgrust as their primary production database. One company with a high tolerance for downtime is deploying it, and he says that deployment will produce the reliability evidence. About the 0.4-beta query engine, Malis says it is "very fast on some workloads" but regresses on others, especially very fast queries, because it was tuned for large OLAP-style (analytical) workloads. It also doesn't yet support some complex queries. Luu also addresses a recent controversy over pgrust's ClickHouse benchmark submission. He finds the cheating accusations false. Malis has acknowledged that submitting a preview build was premature.
Exhibit B: removing bottlenecks nobody tries to remove
Luu asked where time on his machine would go if models ran 10–100x faster. Three things stood out: 4 (a fast code-search tool), Rust compilation, and syscall and filesystem overhead. In "a low single-digit number of hours," with no background in regex engines or compilers, he built three things:
a regex engine that compiles patterns to native code and can be tuned to beat general-purpose libraries on whatever workload he cares about
a ripgrep fork using that compiler, faster on his agent's search workloads (he notes a text index would be the better solution)
a Rust interpreter that he says cut cold builds by about 50x and warm builds by about 2x. He held back by not forking the Rust compiler's front end, because keeping a compatible fork would cost too many tokens.
He thinks this would have taken him a year or more by hand, and that bringing any of it up to open-source quality would still take far more work. For filesystem overhead, switching his development machine from Mac to Linux helped a lot. He goes further: the Unix filesystem API wasn't designed for modern disks, and a developer toolchain built on 5, which bypasses the OS page cache, would once have been absurd to attempt but is doable now.
The cost-model argument is this: ten years ago, someone who wrote a new compiler because theirs was slow was like someone who starts a new 3D engine to make an indie game, and they never shipped. Luu says that instinct no longer matches the actual costs.
Why verification is now the limit
Luu traces how fast this has changed. Building a superhuman AI for the board game Azul took him about 5 hours, and about 20 to make what looked like the strongest one available. At the time, the models misimplemented techniques from papers, and checking their work meant learning the field himself. A friend's newer bot, built with later models, beats his and took less time to build. In Luu's informal evals, a current model passes all registered tests for a from-scratch 6 (a compression format) implementation more than 99% of the time, for about $1. He had to move to harder targets: the IMAP email-protocol spec and Pandoc, which converts between dozens of document formats.
But he says he ends up further from "it just works" with each model generation. The gap between what a model can implement and what it can verify without handholding keeps growing. His answer is to build self-checking setups. The rules of the board game Guards of Atlantis 2 are inconsistent across their official explanations. He set up automated consistency checks across all of them and got close to a correct spec for "a month or two" of a $200/month subscription, which he judged cheaper than writing a clean spec himself. He compares this to fuzzing and property-based testing. People told him those wouldn't work in their domain, and in his experience they always did.
He also invokes Amdahl's law. Doing exactly what you did five years ago, but with agents, gives a modest speedup. The big gains come from choosing work that used to be too expensive. Two more examples: Peter Geoghegan, a Postgres developer, now has a Neovim function that runs clang-format and then 7 (Postgres's code formatter) on a selected block of code. It uses 8, a code parser, to work out which lines to copy back into his file, and it generates missing type definitions from clangd instead of rerunning objdump over the whole binary. Geoghegan calls it a Rube Goldberg device he would never maintain by hand, and says it works perfectly. Malis, meanwhile, has moved pgrust's formal verification from , a model checker for Rust, to , a theorem prover, for the proofs Kani can't handle.
The counterargument
Luu includes a rebuttal from Yossi Kreinin. Kreinin says most problems lack clear pass/fail criteria for agent loops, and most people, himself included, struggle to reason about large black boxes they can constrain but not understand. He compares it to microservices: some teams need them and use them well, and most teams don't and can't. He warns that agent-written performance code tends to be overfit to the benchmarked case, generalizes poorly, and is hard to maintain. A manager convinced that "there's no reason for software to be slow" is, in his words, a reason to "run for cover."
Luu doesn't really argue with this. He says he sees more bugs now than ever. He also notes that a seven-person Anthropic team replacing GitHub internally in five months tells you little, since they have effectively unlimited tokens. His conclusion: other people shipping slop doesn't oblige you to ship it too, if you invest in testing and benchmarking. The post doesn't show how often that discipline actually holds up, and it doesn't include benchmarks for its own speedups.
Remember
pgrust's thorough testing found real Postgres bugs, so the rewrite has paid off even if it never succeeds.
Luu says agents now build faster than they can verify, so self-checking test harnesses are the real bottleneck.
Kreinin warns that without clear pass/fail criteria, ambitious agent-built code becomes an unmaintainable, overfit black box.
Fault-tolerant systems run several copies of a component and accept whatever the majority says. A wrong answer from one copy is outvoted. Modern replicated databases use the same idea with quorums: an operation counts as done only after a majority of replicas agree to it.
Murat Demirbas, a distributed-systems researcher who writes the 1 blog, has reviewed Ananyo Bhattacharya's biography of John von Neumann (1903–1957). His argument is that von Neumann's real talent wasn't raw intelligence but one repeated move: abstraction. Find the smallest set of objects and rules a messy problem is really about, write them down, and move on.
The pattern
It showed up early. At 17, von Neumann defined each number as the set of all numbers before it: zero is the empty set, one is {0}, two is {0, 1}. Demirbas notes this is an 2 with one constructor. In his doctoral thesis von Neumann handled the set-theory paradoxes by separating sets that can be elements of other sets from oversized ones that can't. Demirbas calls it a type system in which the paradox becomes a type error.
The same move recurs:
Quantum mechanics: he showed that the rival matrix and wave theories were one theory described in two coordinate systems.
Economics: from a few consistency rules for rational choice he derived a numeric utility scale, and with Oskar Morgenstern he founded game theory in a 600-page book.
Computing: his 1945 3 report described the stored-program machine, with one memory for both instructions and data. He made sure it circulated publicly so no one could patent it.
The parts closest to distributed systems
In 1952, with vacuum tubes failing constantly, he asked whether an arbitrarily reliable machine could be built from parts guaranteed to fail, using redundancy and majority voting, and how much redundancy that would take. Demirbas traces 4, quorums and 5 (a protocol for getting replicas to agree on an order of operations) to this question. Von Neumann's self-reproducing automaton solved the infinite-blueprint problem by using one description twice: read as instructions to build the machine, then copied as data for the offspring. That model came before the discovery of DNA's structure and produced the first 6.
When the model was too small
Demirbas doesn't excuse the failures. Von Neumann dismissed John Nash's non-cooperative equilibrium as trivial. He publicly urged a preemptive nuclear strike on the USSR. Demirbas calls that minimax reasoning applied to a Cold War modeled, too simply, as a two-player zero-sum game. Yet the same man championed Turing, Mandelbrot and the statistician David Blackwell.
His 1955 essay "Can We Survive Technology?" ends without a model. It rejects bans as a "pseudosolution" and offers only "a long sequence of small, correct decisions." Demirbas suggests von Neumann may have learned what a formal model is worth when its assumptions are shaky.
Murat Demirbas, a distributed-systems researcher who writes the 1 blog, has reviewed Ananyo Bhattacharya's biography The Man from the Future: The Visionary Life of John von Neumann. He listened to it on Bay Area commutes. He opens with Edward Teller's eulogy line that von Neumann "enjoyed thinking" and "almost nothing else", then narrows it. Demirbas argues that the real addiction was more specific: abstraction. Arrive in a field, find the smallest set of objects and axioms the mess is actually about, write them down so people can argue about the right thing, and leave before the theorems fall out.
The range
The list is long for a 53-year life. It covers the foundations of set theory, the mathematical formulation of quantum mechanics, operator algebras (still called von Neumann algebras), ergodic theory, game theory and expected utility theory. It also includes the 2, the stored-program computer, numerical weather prediction, fault-tolerant computing and self-reproducing automata. It ends with the implosion lens for the Nagasaki bomb and a decade of hawkish nuclear strategy.
Where the habit came from
Demirbas picks out two things from von Neumann's Budapest childhood. First, his banker father ran dinner as a seminar. He reported on his own day, each son presented what he had been reading, and the family argued. Visiting business clients could be questioned by the boys. Second, the father had the sons learn many languages because he expected the family might have to flee. They did flee, during the communist takeover and the antisemitic massacres that followed it. The boy had no formal schooling until he was ten. At the Fasori Gymnasium, the math teacher quickly handed him to a private tutor, Gábor Szegő, who later chaired Stanford's math department.
The first abstractions came early. At 17, von Neumann defined each ordinal number as the set of all numbers before it. Zero is the empty set {}, one is {0}, two is {0, 1}, and so on into the infinite ordinals. Demirbas notes that this is an 3 with a single constructor. In his doctoral thesis von Neumann tackled the set-theory paradoxes, such as Russell's set of all sets that don't contain themselves. He split sets into ordinary ones, which can be elements of other sets, and oversized ones, which can be discussed but never used as elements. Demirbas calls this essentially a type system, under which the paradox becomes a type error. In both cases von Neumann replaced a familiar object with the smallest thing that behaves the same way.
The same move, field after field
Reliability from unreliable parts
This section is closest to the reader's field. Vacuum tubes failed constantly, and the standard engineering response was to build better tubes. In 1952 Caltech lectures, "Probabilistic Logics and the Synthesis of Reliable Organisms from Unreliable Components", von Neumann asked a different question. Could components that are guaranteed to fail be combined, through redundancy and majority voting, into an arbitrarily reliable machine? And how much redundancy would that take? Demirbas traces 7, quorums and 8 back to this framing. A replicated state machine is a service copied across servers that apply the same operations in the same order. Paxos is a protocol for getting those servers to agree on that order despite failures.
Self-reproduction
A self-copying machine seems to need a blueprint of itself, which must contain a blueprint of the blueprint, and so on forever. Von Neumann broke the regress by giving one description two uses. A universal constructor reads a tape as instructions to build the machine, then copies the same tape as uninterpreted data and attaches the copy to the offspring. Demirbas points out that this is the stored-program idea again. Published in 1948–49, it predicted the shape of biological reproduction (a stored description read in two distinct ways) before Watson and Crick described DNA's structure in 1953. The 29-state model he built to prove it was the first 9, a grid of cells that each update by simple local rules. Conway's Game of Life and later artificial-life work descend from it.
Where the habit failed
Demirbas is direct about the costs. The game theory book is built around zero-sum games and stable coalitions, yet most of the world isn't zero-sum. When John Nash brought him the non-cooperative equilibrium, von Neumann dismissed it as a trivial fixed-point argument and misjudged how much it mattered. Worse, he publicly argued for a preemptive nuclear strike on the USSR ("why not today?") while sitting on the Atomic Energy Commission. Demirbas reads this as minimax applied to a model that was too simple. Treat the Cold War as a two-player zero-sum game and assume the Soviets would use the bomb, and the math says strike first. Ulam's verdict was "a too exclusively rational point of view."
The man was also generous. He championed Turing and Mandelbrot, pushed Princeton to accept the Black statistician David Blackwell, and testified for Oppenheimer despite not sharing his politics.
The last word
In his 1955 essay "Can We Survive Technology?", which also mentions global warming, von Neumann rejects banning dangerous technologies as a "pseudosolution". He argues that the sciences are too intertwined and that any ban would have to be worldwide. All that remains, he writes, is "a long sequence of small, correct decisions" made with "patience, flexibility, intelligence." Demirbas finds it telling that the master of abstraction offered no model here. He suggests that nuclear strategy may have taught von Neumann what a formal model is worth when its assumptions are shaky and the stakes are high. The essay doesn't settle that question. It stays a reading of one man's career, not a method you could apply.
Remember
Majority voting over unreliable parts, the root of quorums and Paxos, began as von Neumann's 1952 question about failing vacuum tubes.
Instructions and data sharing one memory appears twice in his work: EDVAC and the self-reproducing automaton.
A clean model built on wrong assumptions produced his call for a nuclear first strike.
Quantum mechanics. At Göttingen, Heisenberg's matrix mechanics and Schrödinger's wave mechanics gave the same predictions but suggested different pictures of reality. Von Neumann proved they were one theory, two coordinate systems on the same 4 (an infinite-dimensional vector space). His 1932 book set this out rigorously, and Bhattacharya calls it still the most watertight formulation. On the measurement problem, he showed that it doesn't matter mathematically where you put the line between the quantum system and the observer. That line is now called the von Neumann cut.
Game theory. In 1928 he proved the 5: every two-player zero-sum game has a solution, possibly a mixed (randomized) strategy, as in rock-paper-scissors. Years later the economist Oskar Morgenstern was stuck on a loop. Any intervention in an economy changes behavior and invalidates the model used to design it. Demirbas calls this a liveness bug. Working part-time over about 18 months, the two wrote the 600-page Theory of Games and Economic Behavior (1944). It included an axiomatization of expected utility: from a few consistency rules a rational chooser must follow, you can derive a numeric utility scale.
The computer. In 1945 his First Draft of a Report on the 6 laid out the stored-program architecture: one memory holding both instructions and data, a control unit, an arithmetic unit, and input/output. He insisted it circulate publicly, which made the design unpatentable. Demirbas reads this as an early open-source act. The IAS machine design spread the same way, producing copies such as MANIAC, JOHNNIAC, ILLIAC and SILLIAC. With Stanislaw Ulam he invented the Monte Carlo method and then pseudorandom number generation to feed it. His team also ran the first computerized weather forecast, in 1950.