Live data from Hacker News

Turso is an in-process SQL database, compatible with SQLite

github.com

11–20 of 109 posts

Re: Turso is an in-process SQL database, compatible with SQLite

#11
post #9

Earlier quoted context omitted.

One quick thing I can think of is multiple writers [0] [0]: https://turso.tech/blog/beyond-the-single-writer-limitation-...

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.

Re: Turso is an in-process SQL database, compatible with SQLite

#13
post #10

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 othe…

There is. For example, four months ago [0] they've accidentally stumbled upon about an explicitly documented quirk of SQLite file format.

[0] https://news.ycombinator.com/item?id=45101854

Re: Turso is an in-process SQL database, compatible with SQLite

#15
post #11
post #9

Earlier quoted context omitted.

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.

Re: Turso is an in-process SQL database, compatible with SQLite

#17
post #16

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/

Re: Turso is an in-process SQL database, compatible with SQLite

#18

Earlier quoted context omitted.

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?

Re: Turso is an in-process SQL database, compatible with SQLite

#19
post #7

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?
Post reply on HN