I never read this article by the C developers before.
It's so odd to read a level headed C vs. Rust take on the internet.
Deep dive into Turso, the “SQLite rewrite in Rust”
111–120 of 154 posts
Re: Deep dive into Turso, the “SQLite rewrite in Rust”
#112Related. Others? Turso is an in-process SQL database, compatible with SQLite - https://news.ycombinator.com/item?id=46677583 - Jan 2026 (102 comments) Beyond the SQLite single-writer limitation with concurrent writes - https://news.ycombinator.com/item?id=45508462 - Oct 2025 (70 comments) An adventure in writing compatible systems - https://news.ycombinator.com/item?id=45059888 - Aug 2025 (12 comments) Introducing th…
How SQLite is tested - https://news.ycombinator.com/item?id=46303277
That one's always a good read, particularly the discussion of the tension between 100% coverage testing and defensive programming. We go for maximum defensive programming, so huge numbers of code paths that can't be exercised in testing but that will prevent things running off into the weeds if something does manage to trigger them. Another organisation in contrast had a client who required 100% code coverage in testing so they spent six months removing all the non-testable defensive code in their code base.
Re: Deep dive into Turso, the “SQLite rewrite in Rust”
#113I never read this article by the C developers before. It's so odd to read a level headed C vs. Rust take on the internet. https://sqlite.org/whyc.html
I'm not sure I buy this from a technical perspective. Rust already meets almost all of the criteria laid out at the end of this post. By all means keep using C if you like it, but the rust team has done an excellent job over the last few years addressing most of these issues.
> - Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring.
Rust moves at a pretty glacial pace these days. Slower than C++ for sure. There haven't been any big, significant changes to the language since async. Code that compiles today should compile indefinitely. (And the rust compiler authors check this on every release, by recompiling basically everything in crates.io to make sure.)
> - Rust needs to demonstrate that it can be used to create general-purpose libraries that are callable from all other programming languages.
Rust matches C in this regard. You can import & export C functions from rust very easily. The consumer of the foreign function interface have no idea they're calling rust and not C.
> - Rust needs to demonstrate that it can produce object code that works on obscure embedded devices, including devices that lack an operating system.
Rust works pretty well on raw / embedded hardware via #[no_std]. There's a few obscure architectures supported by gcc and not llvm (and by extension rust). But it generally works great. I'd love to know what the real blocker platforms are (if any).
> - Rust needs to pick up the necessary tooling that enables one to do 100% branch coverage testing of the compiled binaries.
Uh, I think this is possible today? Rustrover (intellij) can certainly produce coverage reports. This doesn't feel out of reach.
> - Rust needs a mechanism to recover gracefully from OOM errors.
True. You can override the global allocator for a program and use that to detect OOM. But recovering from OOM in general is tricky. I personally wish rust's handling of allocators looked more like zig.
> - Rust needs to demonstrate that it can do the kinds of work that C does in SQLite without a significant speed penalty.
Rust and C are pretty much even when it comes to performance. Rust binaries are often a bit bigger though.
Re: Deep dive into Turso, the “SQLite rewrite in Rust”
#114I never read this article by the C developers before. It's so odd to read a level headed C vs. Rust take on the internet. https://sqlite.org/whyc.html
I'm not sure I buy this from a technical perspective. Rust already meets almost all of the criteria laid out at the end of this post. By all means keep using C if you like it, but the rust team has done an excellent job over the last few years addressing most of these issues. > - Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring. Rust moves at a pretty glacial pac…
The criteria were laid out in 2019 [0]. It was less clear then.
> If you are a "rustacean" and feel that Rust already meets the preconditions listed above, and that SQLite should be recoded in Rust, then you are welcomed and encouraged to contact the SQLite developers privately and argue your case.
It seems like the criteria are less of things the SQLite developers are claiming Rust can't do and more that they are non-negotiable properties that need to be considered before even bringing the idea of a rust version to the team.
I think it is at least arguable that Rust does not meet the requirements. And they did explicitly invite private argument if you feel differently.
0: https://web.archive.org/web/20190423143433/https://sqlite.or...
Re: Deep dive into Turso, the “SQLite rewrite in Rust”
#115I never read this article by the C developers before. It's so odd to read a level headed C vs. Rust take on the internet. https://sqlite.org/whyc.html
I'm not sure I buy this from a technical perspective. Rust already meets almost all of the criteria laid out at the end of this post. By all means keep using C if you like it, but the rust team has done an excellent job over the last few years addressing most of these issues. > - Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring. Rust moves at a pretty glacial pac…
> Rustrover (intellij) can certainly produce coverage reports.
See https://sqlite.org/testing.html#statement_versus_branch_cove...>. Does Rustrover produce branch coverage reports?
Re: Deep dive into Turso, the “SQLite rewrite in Rust”
#116Earlier quoted context omitted.
I'm not sure I buy this from a technical perspective. Rust already meets almost all of the criteria laid out at the end of this post. By all means keep using C if you like it, but the rust team has done an excellent job over the last few years addressing most of these issues. > - Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring. Rust moves at a pretty glacial pac…
> Rustrover (intellij) can certainly produce coverage reports. See https://sqlite.org/testing.html#statement_versus_branch_cove... >. Does Rustrover produce branch coverage reports?
Yes! A quick google brings up cargo-llvm-cov[1], which is a rust wrapper around llvm source code coverage. It has an unstable --branch command for branch coverage, but branch coverage currently has some language level limitations[2].
Re: Deep dive into Turso, the “SQLite rewrite in Rust”
#117Earlier quoted context omitted.
I'm not sure I buy this from a technical perspective. Rust already meets almost all of the criteria laid out at the end of this post. By all means keep using C if you like it, but the rust team has done an excellent job over the last few years addressing most of these issues. > - Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring. Rust moves at a pretty glacial pac…
The criteria were laid out in 2019 [0]. It was less clear then. > If you are a "rustacean" and feel that Rust already meets the preconditions listed above, and that SQLite should be recoded in Rust, then you are welcomed and encouraged to contact the SQLite developers privately and argue your case. It seems like the criteria are less of things the SQLite developers are claiming Rust can't do and more that they are no…
Ah, I assumed the page was written recently due to this message at the bottom:
>> This page was last updated on 2025-05-09 15:56:17Z > I think it is at least arguable that Rust does not meet the requirements
Absolutely. The lack of clean OOM handling alone might be a dealbreaker for sqlite. And I suspect sqlite builds for some weird platforms that rustc doesn't support.
But I find it pretty weird reading comments about how rust needs prove it performs similarly to C. Benchmarks are just a google search away folks.
> And they did explicitly invite private argument if you feel differently.
Never.
Its not up to me what language sqlite is written in. Emailing the sqlite authors to tell them to rewrite their code in a different language would be incredibly rude. They can write sqlite in whatever language they want. My only real choice is whether or not I want to use their code.
Re: Deep dive into Turso, the “SQLite rewrite in Rust”
#118Earlier quoted context omitted.
> test suite which is something lacking in SQLite You must be kidding. Last time I checked, sqlite was mostly extensive test suites.
It's covered in the article. The full SQLite test suite isn't open source, so you (the third party) don't have the same confidence in your modifications as the SQLite team does.
1. Only if you modify it. There is a free test suit, and You can license the non-free test suit.
2. Compare to the test in Turso, the test in Turso is just kids toy.
Re: Deep dive into Turso, the “SQLite rewrite in Rust”
#119Earlier quoted context omitted.
They're not aiming at replacing SQLite-in-C with SQLite-in-Rust, they're doing this so they can implement more additional functionality faster than with C's chainsaw-juggling-act semantics and the inability to access the proprietary SQLite test suite. See the features and roadmap at https://github.com/tursodatabase/turso
IMHO breaking free of SQLite's proprietary test suite is a bigger driver than C vs Rust. Turso's Limbo announcement says exactly that: they couldn't confidently make large architectural changes without access to the tests. The rewrite lets them build Deterministic Simulation Testing from scratch, which they argue can exceed SQLite's reliability by simulating unlikely scenarios and reproducing failures deterministical…
Having seen way too many "we're going to rewrite $xyz but make it BETTERER!!", I don't give this one much chance of success. SQLite is a high-quality product with a quarter-century of development history and huge amounts of effort, both by the devs and via public use, of testing. So this let's-reinvent-it-in-Rust effort will have to beat an already very good product that's had a staggering amount of development effort and testing put into it which, if the devs do manage to get through it all, will end up being about the same as the existing thing but written in a language that most of the SQLite targets don't work with. I just can't see this going anywhere outside of hardcore Rust devotees who want to use a Rust SQLite even thought it still hasn't got past the fixer-upper stage.
Re: Deep dive into Turso, the “SQLite rewrite in Rust”
#120I'm working on a Django app. This would make production deployment a bit easier.
Also sad that the test suite isn't open source. Would help drive development of the new DB...