Yes, that sets a high bar for us. We plan to use Deterministic Simulation Testing and Antithesis to reach the rigorous testing standards of SQLite.
Limbo comes with a simulator too
6,477 karma · joined June 19, 2014
CaskDB - https://github.com/avinassh/py-caskdb
Blog at https://avi.im/blag
Yes, that sets a high bar for us. We plan to use Deterministic Simulation Testing and Antithesis to reach the rigorous testing standards of SQLite.
Limbo comes with a simulator too
I really love using S3 as a storage backend!
I am not sure how does this affect database integrity or reliably fsync-ing
for e.g. TigerBeetle is another rock solid database which uses async IO. I mentioning it because it is way more mature than Limbo and does a great job at durability
I have been always curious about this. Is there any more public information to this? When one submits a affidavit, do all their work become public domain? Do you highlight the code and get a affidavit with each contribution?
for e.g. in my country India, I don't think it is not possible to get such Govt approved affidavit.
> code of ethics as almost toxic
This is simply not true. Can you tell me where it is being said so?
> then folding “libSQL into the Turso family” within the year.
libSQL was always part of Turso. So, I don't get your point.
> They forked, played politics, added a few features (with some ill-considered incompatibilities), and properly documented zero of them.
Again this is incorrect. There are some docs here: https://github.com/tursodatabase/libsql/tree/main/docs
I am really not sure why are you so angry about libSQL.
This paper came out in April 2024 when Limbo was in its nascent stages. It has seen many improvements since then, one being support for Deterministic Simulation Testing.
We already have a fork, called libSQL. However, the goals of Limbo are far more ambitious and we cannot rewrite some parts step by step. We want to have DST ( Deterministic Simulation Testing), a testing methodology pioneered by Foundation DB and TigerBeetle. It is not easy to do that in an existing codebase
may be! However, Rust makes some things easier. It is also easy to maintain and reiterate
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.
definitely!
I plan to add a batch write API. Also, an API where it buffers till it reaches certain size or a timeout to write to S3
tracking the batch write here: https://github.com/avinassh/s3-log/issues/3
Currently, there is durability guarantee. The call returns only after successful write to S3. This is close to fsync in a single node system. I plan to add a relaxed write mode
I am tracking the issue here: https://github.com/avinassh/s3-log/issues/4
I mostly post stuff about databases, distributed systems and my frustrations with Rust
whats this magic
A couple of my friends who work in the financial domain showed surprise at this post - they had no idea this was possible. I guess most people just assume databases 'just work'?
Hi, author of the post here. I work mostly with SQLite and that's the database I'm most familiar with, hence mentioning it in the title. I have also noted at the bottom:
> Again, this is not a bug. Most databases (except a few) assume that the OS, filesystem, and disk are sound. Whether this matters depends on your application and the guarantees you need.
now I wrote a follow up post - https://avi.im/blag/2024/databases-checksum
I mostly post stuff about databases, distributed systems and my frustrations with Rust
there’s just 1 static binary, all I need to do to deploy it is copy the binary. If there are static files I can just embed them in the binary with embed.