51–60 of 238 posts
disclosure: I work here. I am happy to answer any questions tl;dr We are rewriting SQLite in Rust. It uses Asynchronous I/O, considers WASM as first class, and has Deterministic Simulation Testing support from the beginning. source: https://github.com/tursodatabase/limbo
Earlier quoted context omitted.
That was my take when LibSQL was announced. And it still is and would be my take if LibSQL remains C-coded. But a Rust-coded rewrite of SQLite3 or LibSQL is a different story. The SQLite3 business model is that SQLite3 is open source but the best test suite for it is proprietary, and they don't accept contributions to any of either. This incentivizes anyone who needs support and/or new features in SQLite3 to join the…
Also the very rigid testing makes the rewrite a lot easier to validate.
disclosure: I work here. I am happy to answer any questions tl;dr We are rewriting SQLite in Rust. It uses Asynchronous I/O, considers WASM as first class, and has Deterministic Simulation Testing support from the beginning. source: https://github.com/tursodatabase/limbo
Clearly still in very early days: uv run --with pylimbo --python 3.13 python Then: >>> import limbo >>> con = limbo.connect("/tmp/content.db") thread ' ' panicked at core/schema.rs:186:18: not yet implemented: Expected CREATE TABLE statement note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace With that environment variable: stack backtrace: 0: _rust_begin_unwind 1: core::panicking::panic_fmt…
If this is just a standard sqlite database that you are trying to open, though, I'd have expected it to work.
Limbo has been taken (as the name of a language), so this should be SQuaLor or something...
disclosure: I work here. I am happy to answer any questions tl;dr We are rewriting SQLite in Rust. It uses Asynchronous I/O, considers WASM as first class, and has Deterministic Simulation Testing support from the beginning. source: https://github.com/tursodatabase/limbo
Will you release the code into the public domain, like SQLite?
We're not fans of public domain, which is one of the things that led us to create libSQL in the first place.
It is MIT.
I’ll take the faster c version anyday over the rust. How are those conditional if statements working for you all?
The benchmarks in the post indicate that Limbo is more performant than SQLite, not less.
The goal with that was just to demonstrate that there's nothing really there that is fundamentally slower, and the perf is already on par in the areas where we spent cycles on.
Given the code quality and rigid testing, SQLite is probably the last project that should be rewritten. It'd be great to see all other C code rewritten first!
That was my take when LibSQL was announced. And it still is and would be my take if LibSQL remains C-coded. But a Rust-coded rewrite of SQLite3 or LibSQL is a different story. The SQLite3 business model is that SQLite3 is open source but the best test suite for it is proprietary, and they don't accept contributions to any of either. This incentivizes anyone who needs support and/or new features in SQLite3 to join the…
This is going to sound pedantic, but SQLite is not Open Source. It's Public Domain. The distinction is subtle, but it is important.
Do they claim a clean room implementation?
It seems wise of SQLite to close down their test suite. That's a great idea I wish I had heard about earlier.