26-Crate Workspace · Pure Safe Rust
A clean-room Rust reimplementation of SQLite with , , and across 26 composable crates.
2026-02-273:435758frankensqlite.com
A clean-room Rust reimplementation of SQLite with MVCC concurrency, RaptorQ self-healing, and zero unsafe code. 26-crate workspace delivering the monster database engine.
Read the original article
Comments
> TCL test harness. C SQLite's test suite is driven by ~90,000+ lines of TCL scripts deeply intertwined with the C API. These cannot be meaningfully ported. Instead, FrankenSQLite uses native Rust #[test] modules, proptest for property-based testing, a conformance harness comparing SQL output against C SQLite golden files, and asupersync's lab reactor for deterministic concurrency tests.
If you're not running against the SQLite test suite, then you haven't written a viable SQLite replacement.
I thought I read somewhere that their full test suite is not publicly available?
By messe 2026-03-026:04 The TH3 test suite is proprietary, but the TCL test suite that they refer to is public domain.
I'm not sure where they get their 90k CLOC count though, that seems like it might be an LLM induced hallucination given the rest of the project. The public domain TCL test suite is ~27k CLOC, and the proprietary suite is 1055k CLOC.
By gigatexal 2026-03-027:13 This and this needs Jepsen testing.
The value of SQLite is how robust it is and that’s because of the rigorous test suite.
By littlestymaar 2026-03-025:571 reply Isn't that test suite private though?
The TH3 test suite is proprietary, but the TCL test suite that they refer to is public domain.
I'm not sure where they get their 90k CLOC count though, that seems like it might be an LLM induced hallucination given the rest of the project. The public domain TCL test suite is ~27k CLOC, and the proprietary suite is 1055k CLOC.
By littlestymaar 2026-03-027:371 reply Thanks for the clarification, I appreciate it.
> and the proprietary suite is 1055k CLOC.
Why is the code size of the proprietary test suite even public though?
You can buy access to it.
Any serious SQLite re-implementation should buy it and test against it.
By kelseyfrog 2026-03-028:091 reply The cost of TH3 is listed as "call".
It's much more likely the issue is one of cost, not of seriousity.
By littlestymaar 2026-03-0218:10 Given that the project and websites are entirely vibe-coded, I don't think they passed the call to get a quote.
By andersmurphy 2026-03-028:18 Whats the obsession with concurrent writes?
Single writer will outperform MVCC as long as you do dynamic batching (doesn't prevent logical transactions) and all you have to do is manage that writer at the application level.
Concurrent writers just thrash your CPU cache. The difference between L1 and L3 can be 100x. So your single writer on a single core can outperform 10-100s of cores. Especially when you start considering contention.
Here's sqlite doing 100k TPS and I'm not even messing with core affinity and it's going over FFi in a dynamic language.
https://andersmurphy.com/2025/12/02/100000-tps-over-a-billio...
It's worth scrolling down to the current implementation status part:
https://github.com/Dicklesworthstone/frankensqlite#current-i...
Although I will admit that even after reading it, I'm not exactly sure what the current implementation status is.
By measurablefunc 2026-03-026:111 reply It's fake. It doesn't exist. It never happened. The whole thing is an LLM hallucination. You can notice that it's all half implemented if you read the code: https://github.com/Taufiqkemall2/frankensqlite/blob/main/cra...
By tonyedgecombe 2026-03-0214:061 reply We are going to get overwhelmed with this stuff aren't we.
By measurablefunc 2026-03-0217:52 The people who understand basic logic will be fine but I'm starting to think that's a very small group of people.
