Xiangpeng Hao releases bbtree, an LLM-written Rust B-tree he says is 5x faster than BTreeMap

What Xiangpeng Hao released

Xiangpeng Hao, a database researcher, has released bbtree, an ordered map for the Rust programming language built as a B-tree, and published a long technical write-up about it on 23 October 2026. The library comes as a crate on crates.io under a choice of the MIT or Apache 2.0 licence, has no dependencies, and also works in no_std environments such as embedded systems and kernels.

What has drawn attention beyond Rust circles is how it was made. Hao writes that all of the code is written by large language models, with the output cross-checked by LLMs from different providers, while he steers every design decision and takes responsibility for the result. The post goes further than most developers would: under a heading on the role of LLMs it states that no human can write better code than LLMs. That is Hao's opinion, not a measured result, but it is unusual to see it made about a low-level concurrent data structure that he describes as production-ready.

Hao is not new to the subject. The post says he spent his PhD writing many B-trees, including Bf-Tree, a concurrent index that he and Badrish Chandramouli presented at VLDB 2024 and that runs in production at Microsoft. The crate first appeared on crates.io on 18 October, and version 0.1.5 followed on 22 October, a day before the write-up.

The performance claims

Hao's headline numbers are bold. He says bbtree is five times faster than the BTreeMap in Rust's standard library on a single thread, 12 times faster than the popular crossbeam-skiplist at 96 threads, and uses 30% less memory. The README adds a claim of five times lower p99 latency. A version called unsync::BBTreeMap is meant as a drop-in replacement for the standard BTreeMap and BTreeSet, so existing single-threaded code can switch without changing how it calls the map.

The post also tests bbtree inside real software rather than only in micro-benchmarks. Hao swapped it in for the in-memory skiplist that four log-structured storage engines use to hold recent writes, and ran each project's own benchmarks on one thread of a Ryzen 9 9900X. He reports fjall lookups 2.47 times faster and write batches 3.00 times faster, SlateDB gets 1.71 times faster, Tonbo's 10-million-row writes 6.83 times faster, and Lance's batched puts 4.21 times faster.

In Turso, a rewrite of SQLite in Rust that keeps tables and indexes in memory, he reports random inserts 2.22 times faster and indexed point SELECT queries 1.90 times faster. A companion crate, bbtree-mmap, writes a finished tree to disk so it can be memory-mapped after a restart instead of rebuilt; Hao says the first answer then comes 160 to 2,500 times sooner than with the standard BTreeMap. All of these figures are the author's own, from his hardware and harnesses.

How it gets its speed

The write-up explains the design through a simple cost model: a cache miss costs about 100 nanoseconds, an instruction about half a nanosecond, and traffic between CPU cores fighting over the same memory slightly more than a miss. The library tries to minimise those three things in that order.

To cut cache misses, nodes are sized to hold roughly 16 to 32 entries so they can be searched linearly within a few cache lines. For keys stored on the heap, such as strings, bbtree keeps short fixed-size inline keys beside each entry, an old database technique similar to the German strings used in some query engines, and only reads the full key when the short ones tie. To cut instructions, Hao hand-wrote SIMD search code for x86 AVX-512 and ARM NEON. On an Apple M1 Pro, he says, replacing the compiler's own counting code with hand-written NEON cut a lookup from 1,678 to 407 instructions and from 390 to 174 nanoseconds.

For concurrency, inner nodes are read optimistically with a version lock: a reader notes a node's version, reads it, and checks the version again, retrying if a writer changed it. Leaves, where values live, are latched normally. Freed nodes are kept on a free list rather than returned to the allocator, which the post says avoids the epoch-based memory reclamation many concurrent Rust libraries rely on. Hao reports 180 million operations a second at 96 threads on an AWS c8a.metal-24xl machine, compared with a ceiling of about 10 million for a map behind a single mutex.

Written by LLMs, checked by a human and by machines

The section of the post that matters most for AI-assisted programming is the one on correctness. Hao writes that performance optimisation is easy because a developer can simply ask Claude or Codex to make code ten times faster on a workload, and the models will iterate relentlessly on something measurable. Correctness, he argues, is the hard part, because it is implicit: no prompt can list every rule and no test suite can prove the code right.

His answer is three layers of defence. The first is Hao himself, accountable for the design. The second is review by models from more than one provider. The third is conventional tooling: fuzzing that runs random operations against bbtree and the standard BTreeMap side by side and checks tree invariants after every step; formal proofs of key properties with Verus, a verifier for Rust; and deterministic simulation testing of thread interleavings with AWS's Shuttle library and a tool called ffs. The post says ffs, run by its author, found a race that Shuttle had missed, logged as issue 9 in the repository and since fixed. That approach echoes Anthropic's recent work proving fuzz targets cannot crash, where machine checking rather than human review was the safety net.

How to try it

Developers can add the library with cargo add bbtree. The concurrent BBTreeMap is shared between threads through ordinary references, and the documentation notes a design choice that differs from the standard map: because values can change under concurrent access, operations that expose an entry run a closure while the leaf is latched rather than handing out a long-lived reference. The docs also warn that a closure which calls back into the same map can deadlock.

For the best performance with custom key types, the README asks users to implement the crate's inline key trait, as the standard strings and byte vectors already do, and to use the batched lookup functions where they fit. On x86, the AVX-512 path needs the program to be compiled for the native CPU with Rust 1.89 or later. The README even includes a short guide addressed to coding agents, listing those same tips and asking them to open an issue if they see a performance regression.

Why it matters for AI-written code

bbtree joins a run of projects this month in which AI models wrote most of the code for serious systems software. Theo Browne used Claude Opus 5.5 to port the TypeScript compiler to Rust, and the Lean theorem prover shipped a proof checker that Claude wrote and proved consistent. Meanwhile OpenAI described how it cut ChatGPT storage latency with caching and Rust, a reminder of how much performance work in AI infrastructure depends on fast, safe data structures.

What sets bbtree apart is that its author is a specialist who frames the human role narrowly: setting direction and owning the consequences, not typing code. The post presents the expert's attention, rather than the authorship of each line, as what users are really trusting. Hao puts it as choosing bbtree meaning offloading the attention to him. Whether that model of trust is enough for widely used infrastructure is exactly the debate the release has set off on social media.

Limits and open questions

Every number in the post comes from Hao's own benchmarks. He links his evaluation code and names the machines, which makes reproduction possible, but AI Lookout did not run the library and has not seen independent results. Speedups in benchmarks of other projects also depend on how much of each workload the in-memory map accounts for, so real applications may see much less.

The claim of being production-ready rests on testing and partial verification, not a full proof: Verus proofs cover selected critical properties, such as inline keys sorting the same way as full keys. The crate is days old, at version 0.1.5, and the race found by ffs shows that subtle concurrency bugs did exist. The statement that no human writes better code than LLMs is an opinion that many experienced engineers dispute, and the post does not say which models or how much compute were used.

Why it matters

bbtree is a concrete test of a growing idea: that a domain expert, AI coding models from several vendors and strong automated checking can together produce systems code fast enough and careful enough to compete with libraries built by hand over years. If outside benchmarks and early adopters such as the storage projects in Hao's tests confirm his numbers, it will be a strong data point for that way of working. If bugs surface, it will show where the three guards still fall short.