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.
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 think that async support for multi-read(and write) are part of the reason for the separate Turso library in Rust over the C fork (libSQL). I also wouldn't be surprised if baking in better support for replication was a design goal as well. Being file-format compatible with SQLite is really useful as well.
In the end, the company is a distributed DBaaS provider using a SQLite interface to do so... this furthers that goal... being SQLite compatible in terms of final file structure just eases backup/recovery and duplication options.
I think being able to self-host either in an open/free and commercial/paid setting is also going to be important to potential users and customers... I'm not going to comment on the marketing spin, as it is definitely that.
IIRC, multiple writers in SQLite is supported, their writes will just be serialized. What you don't have is concurrent writes. But, given SQLite writes are so fast, in practices it's not really a big deal.
If you haven't used SQLite in a real project with heavy writes, I'd say you do it. SQLite is WAY more powerful than people tend to think of it.
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.
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
A gotcha, if you are expecting compatibility with sqlite. You can't set PRAGMA journal_mode=WAL and expect to be able to read database state from another process. Turso will report exclusive lock
Didn't have a good experience with them. One day we suddenly started to experience severe latency spikes, lasting for more than a day, causing timeouts. Unrelated to our DB which was small, even happened on trivial queries - a networking thing on their side. Google showed this to have happened before with certain regions of theirs. If you can't offer a certain region in a stable manner as a DB vendor, don't offer it. The whole point of outsourcing DB mangement is to take care of these things.
I have been asked multiple times on why I chose SQLite and not Turso. I've always responded people that I don't trust an open-source project once it's backed by a VC firm. I've moved away from Redis to Val-Key for same reason, and we have seen the Redis train-wreck in slow-mo. I hope at no point in future Turso ever ends up in that state, but chances are pretty high. At this point the "compatible with SQLite" has become a marketing term IMO, we all know how easy it is to break compatibility here or SQLite to break compatibility.
Which SQLite Go library do you use? My biggest pain with using SQLite in Go is often the libraries and the reliance of CGO which is what puts me off using Turso
Edit: Looking at the go mod file I noticed github.com/mattn/go-sqlite3 which I think is a C wrapper library so I'm assuming you rely on CGO for compiling
We switched our main API from Postgres to Turso last month and haven't looked back. The automatic schema migrations are a nice touch, but I wish the documentation on vector embeddings was a bit more robust. It's wild how much of the modern web is moving back to file-based databases. We switched our main API from Postgres to Turso last month and the cold start times are basically zero now. Are there any plans to support vector columns soon, or is that strictly off-roadmap for now?
When it is ready for production and they implemented DDL to alter tables that D. Hipp just refuses to implement for some reason then I am in. People that feel attacked by this didn't have to deal with the antagonist behaviour of SQLite maintainers toward the community.
26 comments
[ 2.5 ms ] story [ 52.0 ms ] threadTurns 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!
Being written in Rust it's not even a good libc-less drop in choice for a language like Go?
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.
In the end, the company is a distributed DBaaS provider using a SQLite interface to do so... this furthers that goal... being SQLite compatible in terms of final file structure just eases backup/recovery and duplication options.
I think being able to self-host either in an open/free and commercial/paid setting is also going to be important to potential users and customers... I'm not going to comment on the marketing spin, as it is definitely that.
If you haven't used SQLite in a real project with heavy writes, I'd say you do it. SQLite is WAY more powerful than people tend to think of it.
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
Pure stolen valor.
Disgusting.
I have been asked multiple times on why I chose SQLite and not Turso. I've always responded people that I don't trust an open-source project once it's backed by a VC firm. I've moved away from Redis to Val-Key for same reason, and we have seen the Redis train-wreck in slow-mo. I hope at no point in future Turso ever ends up in that state, but chances are pretty high. At this point the "compatible with SQLite" has become a marketing term IMO, we all know how easy it is to break compatibility here or SQLite to break compatibility.
Edit: Looking at the go mod file I noticed github.com/mattn/go-sqlite3 which I think is a C wrapper library so I'm assuming you rely on CGO for compiling