> A database that can scale from in-process to networked is badly needed Why not Postgres? https://pglite.dev
[flagged]
Deep dive into Turso, the “SQLite rewrite in Rust”
51–60 of 154 posts
Re: Deep dive into Turso, the “SQLite rewrite in Rust”
#52Re: Deep dive into Turso, the “SQLite rewrite in Rust”
#53The 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 a…
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
Re: Deep dive into Turso, the “SQLite rewrite in Rust”
#54Earlier 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?
Re: Deep dive into Turso, the “SQLite rewrite in Rust”
#55> ... 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…
Maybe they're saying a rewrite part solves the governance issues not the rust part.
Re: Deep dive into Turso, the “SQLite rewrite in Rust”
#56https://github.com/search?q=repo%3Atursodatabase%2Fturso%20u...
Re: Deep dive into Turso, the “SQLite rewrite in Rust”
#57I’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
That’s hearsay that I haven’t dug into, so I may well be wrong.
Re: Deep dive into Turso, the “SQLite rewrite in Rust”
#58Re: Deep dive into Turso, the “SQLite rewrite in Rust”
#59The 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 a…
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
That's not entirely true. SQLite has a TON of tests that are part of the public domain project: https://github.com/sqlite/sqlite/tree/master/test
They do have a test suite that's private which I understand to be more about testing for different hardware - they sell access to that for companies that want SQLite to work on their custom embedded hardware, details here: https://sqlite.org/th3.html
> SQLite Test Harness #3 (hereafter "TH3") is one of three test harnesses used for testing SQLite.
Re: Deep dive into Turso, the “SQLite rewrite in Rust”
#60Earlier quoted context omitted.
pglite runs in wasm so it should be possible to embed it where you want, like sqlite?
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
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 problem.