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.
I’d imagine this will go a bit like the rust rewrite of sudo etc. Despite the memory safety advantages at least towards the start it still ends up more fragile because the incumbent has years of testing and fixing behind it
I was surprised that the test suit not open source. Some info in https://sqlite.org/testing.html
It looks like some parts are open source and other not. Does anyone know more about the backstory? (It looks like one is a custom program that generate fuzz test. Do they sell it to others SQL engines?)
This is very shallow for a supposed deep dive.
I'm not ready to entertain Turso as an alternative to something that is as battle tested as Sqlite.
The thing that worries me the most about Turso is that rather than the small, stable team running SQLite, Turso is a VC backed startup trying to capitalize on the AI boom. I can easily see how SQLite's development is sustainable, but not Turso's. They're currently trying to grow their userbase as quickly as possible with their free open source offering, but when they have investors breathing down their necks asking about how they're going to get 100x returns I'm not sure how long that'll last. VCs generally expect companies they invest in to grow to $100 million in revenue in 5-10 years. If your use of their technology doesn't help them get there, you should expect to be rugpulled at some point.
I recently benchmarked different SQlite implementations/driver for Node. Better-sqlite3 came out on top of this test: https://sqg.dev/blog/sqlite-driver-benchmark/
There has been a podcast by Developer Voices about Turso: https://m.youtube.com/watch?v=1JHOY0zqNBY
I'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...
> ... most of which can be fixed by a rewrite in Rust
huh? That is clearly not the case. memory bugs - sure. Not having a public test suite, not accepting public contributions, weakly typed columns and lack of concurrency has nothing to do with the language. They're governance decisions, that's it.
>I see this situation trhough the prism of the innovator's dilemma: the incumbent is not willing to sacrifice a part of its market to evolve, so we need a new player to come and innovate.
I don't think the innovators dilemma quite applies in the open source world. Projects are tools, that's it. Preserving a project for the sake of preserving it isn't a good idea.
If people need to run a sqlite db in these exotic places, shedding it means someone else has to build their own tool now that can do it. Sqlite has decided that they care about that, so they support it, so they can't use rust. Seems sound.
Projects coming and going is a good thing in open source, not a bug.
At the current rate of progress I'm wondering how long it will take for llm agents to be able to rewrite/translate complete projects into another language. SQLite may not be the best candidate, due to the hidden test suite. But CPython or Clang or binutils or...
The RIIR-benchmark: rewrite CPython in Rust, pass the complete test suite, no performance regressions, $100 budget. How far away are we there, a couple months? A few years? Or is it a completely ill-posed problem, due to the test suite being tied to the implementation language?
Where is the "networked mode" in Turso? Turso's readme and docs do not mention anything like this
For the Java ecosystem, H2 fills this gap nicely, easily handling both in- memory and remote JDBC access:
I hate to be negative, but where is the deep dive? This is a shallow overview of Turso's features and some of the motivation behind it. Am I missing something?
So the idea is to rewrite it in Rust and drop SQLite? I mean, maybe that’s just how things evolve. But it feels like every project is only a few vibe-coding sessions away from getting rewritten in $LANGUAGE. And I can’t help wondering whether that’s hurting a sustainable open-source ecosystem.
SQLite is a good example: the author built a small ecosystem around it and managed to make a living from open source. Thanks to author's effort, we have a small surface area, extreme stability, relentless focus on correctness.
If we keep rewarding novelty over stewardship, we’ll lose more “SQLite-like” projects—stable cores that entire ecosystems depend on.
> A database that can scale from in-process to networked is badly needed
Why not Postgres? https://pglite.dev
Good article though it kind of stopped just when I thought the deep dive was about to start.
Wow what a terrible and misleading article
let's play a little game known as "count the unsafe"
https://github.com/search?q=repo%3Atursodatabase%2Fturso%20u...
What a breath of fresh air to read a blog not written by AI, with actual human learnings and opinions. Thanks for the write up!
Related. 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 the first alpha of Turso: The next evolution of SQLite - https://news.ycombinator.com/item?id=44433997 - July 2025 (11 comments)
Working on databases from prison - https://news.ycombinator.com/item?id=44288937 - June 2025 (534 comments)
Turso SQLite Offline Sync Public Beta - https://news.ycombinator.com/item?id=43535943 - March 2025 (67 comments)
We will rewrite SQLite. And we are going all-in - https://news.ycombinator.com/item?id=42781161 - Jan 2025 (3 comments)
Limbo: A complete rewrite of SQLite in Rust - https://news.ycombinator.com/item?id=42378843 - Dec 2024 (232 comments)