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?

What's the isolation level? They only mention write-write conflicts.

The reason SQLite's BEGIN CONCURRENT does not greatly increase concurrency (unless you're very careful with your schema and queries) is as much due to page level conflict detection as it is because it enforces serializable isolation.

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.

It natively supports vector embeddings, which seems like it could be nice. The sqlite extensions I've tried for vector embeddings have been a challenge to get working (may just be me though).

> 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

The entire reason behind Turso is that the author had a beef with the sqlite people.