[d1l]

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.

[Joker_vD]

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

[hiddendoom45]

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.

[tracker1]

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.

[ncruces]

You're only file format compatible if you don't use any of the Turso extensions.

Just like STRICT tables, as soon as you use an unsupported feature in your schema, your database becomes incompatible.

With STRICT tables you needed to upgrade SQLite tools.

But if you use something from Turso you're placing yourself outside the ecosystem: the SQLite CLI no longer works, Litestream doesn't work, sqlite_rsync doesn't work, recovery tools don't work, SQLite UIs don't work.

Turso has no qualms with splitting the ecosystem. They consider themselves the next evolution of SQLite. The question is do you want to be part of it?

[joelwallis]

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.

[ako]

I've been using a sqlite alternative to avoid dependencies on a native library. It's go application that uses a native go sqlite reimplementation so i can create platform specific binaries that include all dependencies. Makes installation easier and more reliable.

[formerly_proven]

modernc.org/sqlite is upstream SQLite, compiled to Go using ccgo. Spiritually similar to, say, a WASM build of SQLite. Not a separate reimplementation.

[ncrmro]

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