Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deep dive into Turso, the “SQLite rewrite in Rust”

kerkour.com

Post reply on HN
Print view View original

141–150 of 154 posts

Re: Deep dive into Turso, the “SQLite rewrite in Rust”

#141

Post by adamzwasserman »

pseudohadamard wrote: post #119
adamzwasserman wrote: post #41

Earlier quoted context omitted.

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 effor…

fragmede is correct.

I needed SQLite as a central system DB but couldn't live with single-writer. So I built a facade that can target SQLite, Postgres, or Turso's Rust rewrite through one API. The useful part: mirroring. The facade writes to two backends simultaneously so I can diff SQLite vs Turso behavior and catch divergences before production. When something differs, I either file upstream or add an equalizing shim. Concurrent writes already working is a reasonable definition of success. It's why I'm using it.

Re: Deep dive into Turso, the “SQLite rewrite in Rust”

#142

Post by adamzwasserman »

CharlesW wrote: post #73
adamzwasserman wrote: post #41

Earlier quoted context omitted.

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…

> IMHO breaking free of SQLite's proprietary test suite is a bigger driver than C vs Rust. I don't understand this claim, given the breadth and depth of SQLite's public domain TCL Tests. Can someone explain to me how this isn't pure FUD? "There are 51445 distinct test cases, but many of the test cases are parameterized and run multiple times (with different parameters) so that on a full test run millions of separate…

SQLite's test suite is infamously gigantic. It has two parts: the public TCL tests you're referencing, and a much larger proprietary test suite that's 100x bigger and covers all the edge cases that actually matter in production. The public tests are tiny compared to what SQLite actually runs internally.

Re: Deep dive into Turso, the “SQLite rewrite in Rust”

#143

Post by wredcoll »

adamzwasserman wrote: post #142
CharlesW wrote: post #73

Earlier quoted context omitted.

> IMHO breaking free of SQLite's proprietary test suite is a bigger driver than C vs Rust. I don't understand this claim, given the breadth and depth of SQLite's public domain TCL Tests. Can someone explain to me how this isn't pure FUD? "There are 51445 distinct test cases, but many of the test cases are parameterized and run multiple times (with different parameters) so that on a full test run millions of separate…

SQLite's test suite is infamously gigantic. It has two parts: the public TCL tests you're referencing, and a much larger proprietary test suite that's 100x bigger and covers all the edge cases that actually matter in production. The public tests are tiny compared to what SQLite actually runs internally.

...why does sqlite have proprietary tests??

Re: Deep dive into Turso, the “SQLite rewrite in Rust”

#144

Post by ragall »

wredcoll wrote: post #143
adamzwasserman wrote: post #142

Earlier quoted context omitted.

SQLite's test suite is infamously gigantic. It has two parts: the public TCL tests you're referencing, and a much larger proprietary test suite that's 100x bigger and covers all the edge cases that actually matter in production. The public tests are tiny compared to what SQLite actually runs internally.

...why does sqlite have proprietary tests??

So that enhancements only be practical by hiring the original team.

Re: Deep dive into Turso, the “SQLite rewrite in Rust”

#145

Post by shimman »

fragmede wrote: post #133
shimman wrote: post #103

Earlier quoted context omitted.

I don't think that's fine at all, it's quite a shitty thing to do hoenstly and I'm not surprised it's a VC backed company doing it.

How would you do it then?

I'd probably wouldn't ride the coattails of another open source project that provides hundreds of billions in value for free annually for anyone on this Earth in order to make a quick buck. IDK I have morals and it seems if you want VC funding you must lack them.

It's no different than the hucksters that take public domain books and slut them up in order to make some coin peddling smut.

Re: Deep dive into Turso, the “SQLite rewrite in Rust”

#146

Post by yunohn »

fragmede wrote: post #134
yunohn wrote: post #7

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!

Was this written by an LLM?

Nope, just a human encouraging any attempt by others to publish things without AI assistance.

Harsh to see HN disapproved of my positivity, lesson learned I guess…

Re: Deep dive into Turso, the “SQLite rewrite in Rust”

#147

Post by structural »

wredcoll wrote: post #143
adamzwasserman wrote: post #142

Earlier quoted context omitted.

SQLite's test suite is infamously gigantic. It has two parts: the public TCL tests you're referencing, and a much larger proprietary test suite that's 100x bigger and covers all the edge cases that actually matter in production. The public tests are tiny compared to what SQLite actually runs internally.

...why does sqlite have proprietary tests??

It allows the code to be fully public domain, so you can use it anywhere, while very strongly discouraging random people from forking it, patching it, etc. Even still, the tests that are most applicable to ensuring that SQLite has been built correctly on a new compiler/architecture/environment are made open source (this is great!) while those that ensure that SQLite has been implemented correctly are proprietary (you only need these if you wanted to extend SQLite's functionality to do something different).

This allows for a business model for the authors to provide contracted support for the product, and keeping SQLite as a product/brand without having to compete with an army of consultants wanting to compete and make money off of their product, startups wanting to fork it, rename it, and sell it to you, etc.

It's pretty smart and has, for a quarter century, resulted in a high quality piece of software that is sustainable to produce and maintain.

Re: Deep dive into Turso, the “SQLite rewrite in Rust”

#148

Post by pseudohadamard »

adamzwasserman wrote: post #141
pseudohadamard wrote: post #119

Earlier quoted context omitted.

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 effor…

fragmede is correct. I needed SQLite as a central system DB but couldn't live with single-writer. So I built a facade that can target SQLite, Postgres, or Turso's Rust rewrite through one API. The useful part: mirroring. The facade writes to two backends simultaneously so I can diff SQLite vs Turso behavior and catch divergences before production. When something differs, I either file upstream or add an equalizing sh…

How common is this as a use case though? I wouldn't normally expect to see "SQLite" and "central system DB" in the same sentence. SQL Server, Postgres, 'Orable, MySQL, DB2, but not really something targeted for small-footprint lightweight use.

Re: Deep dive into Turso, the “SQLite rewrite in Rust”

#149

Post by [deleted] »

josephg wrote: post #117
thethirdone wrote: post #114

Earlier quoted context omitted.

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 abo…

[deleted]
Post reply on HN