101–109 of 109 posts
Earlier quoted context omitted.
[flagged]
They are giving their stuff away for free, hence they can do whatever they want. It goes without saying, that spiritual teachings are not there to create quarrel and division.
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…
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…
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?
Earlier quoted context omitted.
I thought the point of Turso was to offer better concurrency than SQLite currently does. A la https://turso.tech/blog/beyond-the-single-writer-limitation-... and https://penberg.org/papers/penberg-edgesys24.pdf Would be great if one of the Turso developers can clarify :)
Honestly, if you care about that level of concurrency, it begs the question of why are you using an in process database in the first place?
Earlier quoted context omitted.
> Amazing test suite. Lol, is that a joke. Seesh. [To be clear, i think sqlite is the hands down winner on this front, no contest. Does the Turso test suite qualify it to be used in safety critical applications? I don't think so]. To your other points - look if it works for you i'm not here to tell you you can't use it. However these features sound more trendy than useful. To me these sound like negatives. A bunch of…
Have you seen the SQLite test suite? AFAIK, it's private/secret/closed. I think that is a part of the argument against SQLite.
I care that sqlite is being tested against it, because i care that sqlite is well tested. i'm not super concerned that part of the test suite is closed source as i dont need to directly use it.
Earlier quoted context omitted.
> I would wonder why anyone would chose Turso over SQLite well, Turso adds features otherwise yeah, there'd be no reason
Ok, `io_uring` (like NVMe but for IO commands from application to kernel) and DBSP (high-grade framework for differential (as in, based on Delta streams/diffs not full updates) compression of "incremental view maintenance", it can keep materialized views synchronously up-to-date with a cost proportional to just the diff (for most typical ones; certain queries can of course be doing things at an intermediate stage tha…
Are there benchmarks comparing turso with io_uring to sqlite (with other config the same)?
io_uring has the potential to be faster but its not garunteed. It might be the same, it might be slower, depending on how you use it. People bragging about the technology instead of the result of using the technology is a bit of a red flag.
Earlier quoted context omitted.
There's a few options... they could be using separate database instances per client to isolate workloads... if there are fewer than 10k or so users at each client, it's pretty doable without a lot of effort, you can further isolate types of data into separate databases as well... other operations can rely on heavy caching, such as maintaining the list of dbs for each client, etc. You CAN use a single database instanc…
If each client has its own database, does that mean you're automating the infra to turn on a new instance for each database, and then routing requests appropriately? Not too hard with k8, I suppose. Or if you add new clients infrequently enough it's a manual task. But you wouldn't do this for each user - it assumes you have some higher level of organization (client/tenant/org/etc). Sounds like these are different way…
And yeah, it's effectively sharing data... My point is there are lots of use cases that can fit in this type of database usage.
Earlier quoted context omitted.
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…
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…
But depending on the need, I'm probably more inclined to reach for something like Turso today than Firebird of I want something I can embed and connect to a server to sync against, for example.
Like most things, it depends.
Earlier quoted context omitted.
Have you seen the SQLite test suite? AFAIK, it's private/secret/closed. I think that is a part of the argument against SQLite.
Do you usually read test suites? I care that sqlite is being tested against it, because i care that sqlite is well tested. i'm not super concerned that part of the test suite is closed source as i dont need to directly use it.
Without seeing it, you have no idea how good it is at all. I'm not knocking the SQLite guys... But it's just a factual statement. It's unknown to most.
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…
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.