I’d imagine there’s an extremely long tail of features and quirks that will take time to iron out even after SQL compatibility is achieved. Looks like it’s still missing some important features like savepoints (!!!), windows and attach database.
I’d be more excited and imagine it would be more marketable if it focused instead on being simply an embedded sql db that allowed multiple writers (for example), or some other use case where SQLite falls short. DuckDB is an example- SQLite but for olap.
I’ve been using it locally and with their hosted offering for awhile now and it’s rock solid other than if I make super deeply nested joins which overflow something. But other that that it’s super fast and cheap I haven’t had to need more than the free tier with a bunch of stuff I host on cloudflare workers
There is. For example, four months ago [0] they've accidentally stumbled upon about an explicitly documented quirk of SQLite file format.
I stumbled on the lock page myself when I was experimenting with writing a sqlite vfs. It's been years since I abandoned the project so I don't recall much including why I was using the sqlitePager but I do recall the lockpage being one of the first things I found where I needed to skip sending page 262145 w/ 4096 byte pages to the pager when attempting to write the metadata for a 1TB database.
I'm surprised they didn't have any extreme tests with a lot of data that would've found this earlier. Though achieving the reliability and test coverage of sqlite is a tough task. Does make the beta label very appropriate.
Is there an example of a company that rewrote something popular in a faster / better language and built a successful business on that? I can think of ScyllaDB and Redpanda but aren't they struggling for the same reasons: not the default, faster horse, costly to maintain, hard to reach escape velocity
Hopefully anything useful and stable in turso will be ported to sqlite
the description as "the next evolution of sqlite" is offensive
D. Richard Hipp has done a universal good for the world by releasing sqlite into the public domain and maintaining it for 25 years
I bet this VC funded knockoff won't see 5
> the description as "the next evolution of sqlite" is offensive
That marketing is really the one thing that keeps me from considering this as a serious option.
To callback to an article a few days ago, it's a signal of dishonest intent [1], and why in the world would I use the alternative built by apparently dishonest people when sqlite is right there and has one of the best track records in the industry.
[1] https://zanlib.dev/blog/reliable-signals-of-honest-intent/
How many times is this going to get shilled? It shows up at least once a month and the people associated with come in talking like it's almost trivial to "build a better sqlite" or that in essence SQLite3 is "deprecated." Give me a f**ing break.
Turso is sqlite with a server client arch. I use them for stashing my llm usage logs all the time. Pretty neat. Plus I'm rooting for them to rewrite sqlite in Rust.
If it is in-process (as the article says), why do you describe it as client / server architecture? If it’s not in-process why compare it to SQLite instead of other client server databases like Postgres?
But I thought turso already had an SQLite-compatible thing, libsqlite!
Turns out this is covered in the readme: libsqlite is a fork (so, presumably C) while turso database is a rust rewrite.
Good luck to the friends at Turso!
Commit history is nuts! These guys are working.
> AGENTS.md
Claude is that's for sure
I'm confused why I would use this when Sqlite exists?
Being written in Rust it's not even a good libc-less drop in choice for a language like Go?
One quick thing I can think of is multiple writers [0]
[0]: https://turso.tech/blog/beyond-the-single-writer-limitation-...
This is a huge differentiator. I built our internal meme platform with Turso. Really fun and easy to use.
How much internal traffic are you generating that single thread sqlite writes can't keep up?
The meme machine cannot be stopped. It's really not that much, but this has the nice side effect of I simply don't need to worry about it.
isn't this just pushing the complexity around? Either my write thread manages the lock, or turso's does.
MVCC is a non-locking algorithm for concurrent writers that the big databases like postgres use (with caveats like aborting some transactions if conflicts would exist). It's not a matter of pushing locks around but allowing multiple threads to operate on the data concurrently.
thanks helpful thanks. seems to have some tradeoffs. I would likely lean toward the simpler thread model but it sounds compelling.
> Turso Database is a project to build the next evolution of SQLite in Rust, with a strong open contribution focus and features like native async support, vector search, and more