Live data from Hacker News

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

kerkour.com

151–154 of 154 posts

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

#151

Earlier quoted context omitted.

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.

SQLite is battle-tested in production at massive scale. Discord handles millions of concurrent users with SQLite clusters. WhatsApp served 900 million users before Facebook acquired them, running on SQLite for message storage. The "lightweight" perception is outdated.

Who knows, maybe 5 years from now, you will say to yourself: that crazy wasn't so crazy after all!

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

#152
post #99

Earlier quoted context omitted.

but the other one has decades of engineering effort and is based on real world problems

But the other one is not available to most and SQLite itself is "open-source" not "open-contributions" so extending SQLite is pretty much impossible at scale: - no way to merge upstream - no way to run full test-suit to be sure everything is tiptop

Indeed. That is a problem for developing SQLite without having an agreement with the developers. That is not a problem for me choosing to use SQLite in my stack.

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

#153

Earlier quoted context omitted.

I don't understand you reply here. Database startups have always had the consistent issue of cloud providers providing managed solutions without contributing back. It is why many moved to or use the AGPLv3 and why there was the whole SSPL controversy in the first place. Running a successful open source database startup is not trivial. None of this applies to SQLite.

I think the point is that that sounds like a potential problem for turso, but it’s not really a problem for everyone else unless some sort of vendor lockin would prevent using open source alternatives. But given the strong compatibility story with the SQLite file format implied already that just doesn’t seem credible.

Yeah I am really not speaking in terms of a risk for all end users, just those who may rely on turso as a company. To assume a startup, no matter how well funded, will survive is naive. There are historically a lot of issues with this business model. This is not a certain failure, but we cannot ignore the challenges companies in a similar space have faced.

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

#154

Earlier quoted context omitted.

You need to be crazy to use an ORM. I personally think that even SQL is redundant. I would like to see a high quality embedded database written in Rust.

Yep, exactly this. It's painful having to switch to another language to talk to the database, and ORMs are the worst kind of leaky abstractions. With Rust, we've finally got a systems language that's expressive enough to do a really good job with the API to an embedded database. The only thing that's really missing is language support for properly ergonomic Cap'n Proto support - Swift has stuff in this vein already.…

interesting points thanks i see my understanding of both orms and how rust (sqlx?) works was both a bit limited.
Post reply on HN