--- title: Bbtree: Fastest Ordered Map | daily.dev description: bbtree is a new Rust ordered map claimed to be the fastest B-tree available. It runs 5 times faster than std's BTreeMap on a single thread and 12 times faster... canonical: https://daily.dev/posts/bbtree-fastest-ordered-map-kd9wa2qfn twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Bbtree: Fastest Ordered Map | daily.dev og:description: bbtree is a new Rust ordered map claimed to be the fastest B-tree available. It runs 5 times faster than std's BTreeMap on a single thread and 12 times faster... og:url: https://daily.dev/posts/bbtree-fastest-ordered-map-kd9wa2qfn og:image: https://api.daily.dev/og/posts/Kd9wa2qFN.png og:image:alt: Bbtree: Fastest Ordered Map 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. # Bbtree: Fastest Ordered Map **[Hacker News](https://daily.dev/sources/hn)** · 26 min read · 10 upvotes · 0 comments ## Summary bbtree is a new Rust ordered map claimed to be the fastest B-tree available. It runs 5 times faster than std's BTreeMap on a single thread and 12 times faster than crossbeam-skiplist at 96 threads, while using 30% less memory. It has zero dependencies, is no_std compatible, and bbtree::unsync::BBTreeMap is a drop-in replacement for std's BTreeMap and BTreeSet. Swapped into the memtables of fjall, SlateDB, Tonbo and Lance, it sped up operations 1.37 to 6.83 times. In Turso it made inserts 2.22 times and indexed SELECTs 1.90 times faster. A companion crate, bbtree-mmap, lets you mmap a saved tree from disk with no rebuild. The code is written entirely by LLMs, checked by fuzzing, Verus verification, and Shuttle/ffs deterministic simulation testing. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How much faster is bbtree compared to Rust's std BTreeMap? bbtree runs about 5 times faster than std's BTreeMap on a single thread for random 64-bit integer keys, and uses roughly 30% less memory. At 96 threads it is 12 times faster than crossbeam-skiplist. It has zero dependencies, is no_std compatible, and its unsync::BBTreeMap variant works as a drop-in replacement for BTreeMap and BTreeSet. _Developers weighing a BTreeMap swap can track benchmarks like these on daily.dev before committing to a change._ ### How does bbtree make B-tree lookups faster using inline keys? bbtree stores fixed-width inline codes (2, 4, or 8 bytes) for each key directly in the node, so one cache line load can cover 8 or more keys instead of one. It only loads the full key when a comparison ties, and uses prefix_keys to skip prefixes shared across all keys in a node, derived from the node's two separators rather than stored per node. _Engineers optimizing cache-sensitive data structures can follow techniques like this on daily.dev._ ### How does bbtree avoid cache coherence contention for concurrent reads? bbtree uses an optimistic version lock per node: a reader reads the version, reads the node, then rereads the version, retrying if it changed, so reads never write to shared cache lines. This lets bbtree reach 180 million operations per second at 96 threads, versus about 10 million ops/sec for a single contended cache line under a Mutex or RwLock. _Teams designing lock-free concurrent data structures can dig into approaches like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 1 discussion and 19 comments across hackernews (as of 2026-10-25). **TL;DR:** The project's performance claims draw interest and some real-world testing offers, but much of the discussion is skeptical, focused on the heavy AI-generated-code framing, marketing language like 'fastest', and gaps between claims and benchmarks. **Sentiment:** 30% positive · 25% mixed · 45% skeptical **The case for** - Some developers found the inline/prefix key design clever and praised the author's prior bf-tree work. - A few people are planning to try it in real workloads (e.g., deduplication in batched request processing) and reported genuine interest after reading the details. - One commenter called it very nice work and offered to apply related cache-coherence optimizations. **The pushback** - Multiple commenters pushed back hard on the claim that 'no human can write better code than LLMs,' calling it bold or trivially disproven by reading the code. - Several called the writeup/site 'AI slop' and were skeptical of the marketing-heavy 'fastest' claims. - One commenter noted the inline-key optimization only applies to a narrow set of types (u64, u128, [u8], str) despite broader claims, and that a checklist item acknowledging this was overlooked. - Another pointed out that for a String-keyed workload with real dictionary data, bbtree used 40% more RAM than std's BTreeMap, contradicting the memory-savings claim. - Someone argued trie-based structures are the real competitors and expressed skepticism that bbtree is genuinely 'fastest'. - There was confusion/criticism over vague terminology like 'model checking' without clarity on what tool was actually used. **By community** - hackernews (mixed): Discussion splits between genuine technical interest and offers to test the library, versus pointed skepticism about AI-authorship claims, marketing language, and discrepancies in benchmark/memory claims. **Hottest debate:** Whether the claim that LLMs write better code than humans is credible, versus the code being dismissed by some as low-quality 'AI slop'. **Open questions** - What model checking tool, if any, was actually used in verification? - Does the narrow type support for inline/prefix keys limit real-world applicability more than the marketing suggests? - How does memory usage compare for string-keyed workloads versus the integer-focused benchmarks cited? **Highlights** > I had a feeling when I read the title and then started reading the post, "this person must be young, probably a student." I think it's ironic that they're using such unscientific terminology like "fastest" given their background https://xiangpeng.systems/. So clearly, it's in the interest of marketing. Maybe some kind of job advertising/resume thing. I can almost guarantee that someone has built a custom btree for their specific domain which is faster than this; and that they probably have some or all of the techniques used in this library that are the main contributors to performance, as well. Prefetching is probably the main one they'll claim, and I know personally of some proprietary implementations which have it. I would like to see some more humility, but I suppose that when you've already resigned your own potential to being below an LLM, then what's the point. It's not possible or useful for them to grow anymore. Some new frontier model next week will outdo whatever ephemerally useful project this person writes, right? That's the logic? > — [ashkankiani on hackernews](https://news.ycombinator.com/item?id=50227444) > Okay I spent an hour trying to read this AI Slop. The prefix key idea is "cool" (see: 1). Gives you sort of "best of both words" B+ tree and B tree behavior. It only applies to `u64`, `u128`, `[u8]`, `str` (and box/vec variants) AFAIT [2]. Their own 'agentic' pre-release checklist calls this out as work that needs to be done prior to release. But then I can be wrong because as OP says > No human can write better code than LLMs. All of the implementation is written by LLMs, and cross-checked by LLMs from different providers. cites: 1. https://bbtree.xiangpeng.systems/post/#apply-to-b-trees 2. https://github.com/XiangpengHao/bbtree/blob/main/bbtree/src/... > — [hugmynutus on hackernews · 1 comments](https://news.ycombinator.com/item?id=50227703) > The dynamic web-paper format is nice for expository instructional articles, but here as much time is spent skipping over dynamic stuff in search of human involvement, of which there is thankfully plenty, than reading about the invention itself. It has at least been copyedited by someone even if the structure feels somewhat robotic. For a map of /usr/share/dict/words (with the value being the dict offset), measuring this consistently using 40% more RAM than std::collections::BtreeMap. Their claim of less memory usage was specifically for integers, so this is more a data point than a refutation. > — [ytxm on hackernews](https://news.ycombinator.com/item?id=50230535) > The real competitors to a Btree like data structure are trie based structures, such as burst tries, (optimised) q-fast and p-fast tries, level compressed tries, bucketed tries, path compressed tries, etc Also optimised stratified trees (van emde boas) implementations where key length permits. Full comparison based structures are rarely necessary: ints, floats, strings, etc can be dealt with by lexicographic structures Tries in particular work outrageously well on (unrealistic) uniform random data with log-logarithmic operation times As a result, I’m skeptical of “fastest” here B trees are great though, good work! > — [nicknash on hackernews](https://news.ycombinator.com/item?id=50230254) > > No human can write better code than LLMs. Bold claim... > — [tyilo on hackernews · 2 comments](https://news.ycombinator.com/item?id=50226925) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50223777) · 125 points · 19 comments ## Similar posts on daily.dev - [microsoft/bf-tree: Bf-Tree is a modern read-write-optimized concurrent larger-than-memory range index in Rust from MS Research.](https://daily.dev/posts/microsoft-bf-tree-bf-tree-is-a-modern-read-write-optimized-concurrent-larger-than-memory-range-inde-iwzsxcs0g) · Hacker News · 0 upvotes · 0 comments - [Rust zero-cost abstractions vs. SIMD](https://daily.dev/posts/rust-zero-cost-abstractions-vs-simd-u3pwvyd72) · Lobsters · 34 upvotes · 2 comments - [6× faster binary search: from compiled code to mechanical sympathy](https://daily.dev/posts/6-faster-binary-search-from-compiled-code-to-mechanical-sympathy-kooq3tqdq) · Planet Python · 1 upvotes · 0 comments --- Tags: [#rust](https://daily.dev/tags/rust) [View this post on daily.dev](https://daily.dev/posts/bbtree-fastest-ordered-map-kd9wa2qfn) ```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":"Bbtree: Fastest Ordered Map","url":"https://daily.dev/posts/bbtree-fastest-ordered-map-kd9wa2qfn","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/bbtree-fastest-ordered-map-kd9wa2qfn"},"datePublished":"2026-10-25T01:13:26.783Z","dateModified":"2026-10-25T12:29:25.584Z","description":"bbtree is a new Rust ordered map claimed to be the fastest B-tree available. It runs 5 times faster than std's BTreeMap on a single thread and 12 times faster...","image":"https://media.daily.dev/image/upload/s--HRgLpUt6--/f_auto/v1722860399/public/Placeholder%2003","thumbnailUrl":"https://media.daily.dev/image/upload/s--HRgLpUt6--/f_auto/v1722860399/public/Placeholder%2003","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/bbtree-fastest-ordered-map-kd9wa2qfn","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":10},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"rust","timeRequired":"PT26M"} {"@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":"Bbtree: Fastest Ordered Map"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/bbtree-fastest-ordered-map-kd9wa2qfn#faq","mainEntity":[{"@type":"Question","name":"How much faster is bbtree compared to Rust's std BTreeMap?","acceptedAnswer":{"@type":"Answer","text":"bbtree runs about 5 times faster than std's BTreeMap on a single thread for random 64-bit integer keys, and uses roughly 30% less memory. At 96 threads it is 12 times faster than crossbeam-skiplist. It has zero dependencies, is no_std compatible, and its unsync::BBTreeMap variant works as a drop-in replacement for BTreeMap and BTreeSet. Developers weighing a BTreeMap swap can track benchmarks like these on daily.dev before committing to a change."}},{"@type":"Question","name":"How does bbtree make B-tree lookups faster using inline keys?","acceptedAnswer":{"@type":"Answer","text":"bbtree stores fixed-width inline codes (2, 4, or 8 bytes) for each key directly in the node, so one cache line load can cover 8 or more keys instead of one. It only loads the full key when a comparison ties, and uses prefix_keys to skip prefixes shared across all keys in a node, derived from the node's two separators rather than stored per node. Engineers optimizing cache-sensitive data structures can follow techniques like this on daily.dev."}},{"@type":"Question","name":"How does bbtree avoid cache coherence contention for concurrent reads?","acceptedAnswer":{"@type":"Answer","text":"bbtree uses an optimistic version lock per node: a reader reads the version, reads the node, then rereads the version, retrying if it changed, so reads never write to shared cache lines. This lets bbtree reach 180 million operations per second at 96 threads, versus about 10 million ops/sec for a single contended cache line under a Mutex or RwLock. Teams designing lock-free concurrent data structures can dig into approaches like this on daily.dev."}}]} ```