Hacker News Reader

Hacker News

Comment by XorNot | Hacker News Reader

Full thread

XorNot

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?

View on HN

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.

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.

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.

Reply on news.ycombinator.com