KvSQL reads a row by its key straight from storage, with no query parsing, and answers SQL about the same rows. One file, one transaction across both, and indexes that stay right whichever way a row was written. Embed the engine, or run the server and talk to it over HTTP.
20,000
Simulated power cuts in one recorded run, with no commit lost or torn
30,000
Random SQL statements in one run, every answer the same as SQLite
100
Times a busy kvsqld server was killed, with every confirmed write still there
None
External dependencies in the engine. It uses only the Rust standard library
From one recorded run of the project's test script on a 2-vCPU Linux container, October 22, 2026. The run's full output is in the repository under test/results/latest.
release
KvSQL 0.1.0 is out. It’s a key-value store and an SQL database that keep one copy of the data between them. Read a row by its key and it comes straight from the …
explainer
Think of a cloakroom. At one window you hand over a ticket and get your coat back. Nobody searches, nobody asks what colour it was. At another window you can ask the …
testing
A database makes one promise above the rest. When it says a commit is done, the data is there, even if the power goes a moment later. And if the power goes during a …
release
KvSQL 0.2.0 is out. Two things changed. A commit now syncs to disk once instead of twice, and SQL has prepared statements that keep their compiled plan. Both came out of …
case studies
A checkout touches several things that must change together. The cart goes away, an order appears with its lines, and the stock goes down. If the power fails halfway, the …
case studies
An edge gateway sits between a set of devices and the rest of the world. Sensors post readings to it, a dashboard on the same network shows the latest value per device, …
case studies
A web application checks its session table on every request. A token comes in, and the app needs the user behind it, fast. Once in a while somebody wants a different view …
benchmarks
KvSQL’s claim is a fast path by key that skips the SQL machinery, on the same records SQL reads. A claim like that needs a measurement, and the obvious yardstick is …
use examples
A response cache has two jobs that pull in different directions. On a hit, it has to find one entry by its key as fast as possible. Now and then it has to throw away …
If you are weighing KvSQL for a project, found something that doesn't work, or have a workload worth testing, write to the project.