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

71–80 of 154 posts

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

#71

Post by groundzeros2015 »

dlisboa wrote: post #63
groundzeros2015 wrote: post #48

Earlier quoted context omitted.

Without the test suite isn’t even more likely to have stability problems?

Maybe. It's hard to know what kind of issues that test suite covers. If memory safety is the main source of instability for the C implementation then the Rust implementation won't be too affected without the test suite. Same if it focus a lot on compatibility with niche embedded platforms and different OSes, which Turso won't care to lose. "Stability" is a word that means different things for different use cases.

Coverage is described on the SQLite website

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

#72

Post by IshKebab »

thisislife2 wrote: post #37
fulafel wrote: post #29

Earlier 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

In other words, they are creating their own database and hitching on to the SQLite brand to market it. (That's fine though).

No that's completely incorrect. It's compatible with SQLite, not just in the same spirit:

> SQLite compatibility for SQL dialect, file formats, and the C API

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

#73

Post by CharlesW »

adamzwasserman wrote: post #41
fulafel wrote: post #29

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

> 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 tests are performed." - https://sqlite.org/testing.html

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

#74

Post by 9rx »

groundzeros2015 wrote: post #48
fulafel wrote: post #29

Earlier 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

Without the test suite isn’t even more likely to have stability problems?

Not likely. The alternative was for them to modify SQLite without the test suite and no obvious indication of what they would need to do to try to fill in the gaps. Modifying SQLite with its full test suite would be the best choice, of course, but one that is apparently[1] not on the table for them. Since they have to reimagine the test suite either way, they believe they can do a better job if the tests are written alongside a new codebase.

And I expect they are right. Trying to test a codebase after the fact never goes well.

[1] With the kind of investment backing they have you'd think they'd be able to reach some kind of licensing deal, but who knows.

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

#75

Post by bigstrat2003 »

iamrobertismo wrote: post #53
hu3 wrote: post #38

Earlier quoted context omitted.

I too am weary of VC incentives but: 1) It's MIT licensed. Including the test suite which is something lacking in SQLite: https://github.com/tursodatabase/turso 2) They have a paid cloud option to drive income from: https://turso.tech/pricing

The MIT licensing makes this even less trustworthy. I can image a major cloud or fly.io just proprietary forking them as a service, as cloud providers have done for years.

So what? The MIT licensed original will still be there, you don't lose out on anything if that happens. And also, SQLite itself is public domain, so by your logic we shouldn't trust SQLite either. Which is crazy.

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

#76

Post by duped »

9rx wrote: post #60
duped wrote: post #26

Earlier quoted context omitted.

Why would I want wasm for an embedded database? It's not a feature, quite an anti-feature frankly. edit: it looks like pglite is only useful for web apps

> it looks like pglite is only useful for web apps Where else other than web apps (herein meaning network-attached database servers that, more often than not, although not strictly so, use HTTP as the transport layer) are at meaningful risk of bumping up against SQLite write contention? If your mobile/desktop app has that problem, it is much more likely that you have a fundamental design issue and not a scaling probl…

I'm not sure I follow what that has to do with embedding a database into your application

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

#77

Post by einsteinx2 »

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…

The irony is if they only had the public domain tests, no one would complain even though it would mean the exact same number of open source tests.

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

#78

Post by iamrobertismo »

bigstrat2003 wrote: post #75
iamrobertismo wrote: post #53

Earlier quoted context omitted.

The MIT licensing makes this even less trustworthy. I can image a major cloud or fly.io just proprietary forking them as a service, as cloud providers have done for years.

So what? The MIT licensed original will still be there, you don't lose out on anything if that happens. And also, SQLite itself is public domain, so by your logic we shouldn't trust SQLite either. Which is crazy.

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.

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

#79

Post by digitalPhonix »

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…

The next bullet point:

> 2. The TH3 test harness is a set of proprietary tests…

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

#80

Post by CharlesW »

digitalPhonix wrote: post #79
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…

The next bullet point: > 2. The TH3 test harness is a set of proprietary tests…

Of course, but how does that make the allegation not FUD?
Post reply on HN