KvSQL Engine on KvSQL.com

KvSQL Launches With an Embedded Engine and a Database Server on One Set of Records

Thu, 22 Oct 2026 00:00:00 +0000

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 storage tree, with nothing parsed or planned. Ask SQL about the same rows and it reads the same bytes. One transaction covers both, and an index stays right whichever way a row was written.

The release has two products. KvSQL Engine is a Rust library you put in your own program: one file on disk, no server, and no dependencies beyond the Rust standard library. KvSQL DB is built on it: kvsqld serves a database file over HTTP with JSON, and kvsql is a shell that talks to the server or opens a file directly.

Why Key Lookups and SQL Belong on the Same Records

Thu, 22 Oct 2026 00:00:00 +0000

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 attendant for every blue coat left after nine o’clock, and somebody has to go through the racks to answer. Both are useful. A database that only has the first window is a key-value store. One that only has the second is an SQL database.

How KvSQL Was Tested With Power Cuts, Killed Processes and 30000 Statements Checked Against SQLite

Thu, 22 Oct 2026 00:00:00 +0000

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 commit, the file holds the whole transaction or none of it, never part. Most of KvSQL’s tests are aimed at that promise, from several sides.

All the figures below come from one recorded run of the project’s test script, scripts/record-results.sh, on a Linux container with two virtual CPUs, on October 22, 2026. The full output is in the repository under test/results/latest. CI runs the same script on Linux and macOS on every change.

Case Study: A Checkout That Is Never Half Done, Tested With 1200 Power Cuts

Thu, 22 Oct 2026 00:00:00 +0000

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 worst outcomes are an order with the stock never taken, or a paid order with the cart still sitting there. With a key-value store for carts and an SQL database for orders, those are two systems and two commits, and somebody has to write the cleanup for the gap between them.

Case Study: Sessions and Reporting in One Store Instead of Two

Thu, 22 Oct 2026 00:00:00 +0000

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 of the same data: how many sessions are live per country, or every session of one user, revoked at once when a password changes. Teams often split this in two, with sessions in Redis for speed and a copy in SQL for the reports and the bulk revokes.

KvSQL Against SQLite on the Same Machine: Key Reads, SQL Reads and Synced Commits

Thu, 22 Oct 2026 00:00:00 +0000

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 SQLite. It’s the most used embedded database there is, and it’s very good. So the project’s test script runs a benchmark against SQLite every time it records results, and saves it next to the test output.

The figures here are from the recorded run of October 22, 2026, on a Linux container with two virtual CPUs. The full table, with every condition, is bench.md in the repository. A container like this is noisy: between runs on the same day, single figures moved by 20 to 30 percent. Treat the gaps below as rough sizes.

Use Example: A Cache With Expiry Using Key Reads and an SQL Sweep

Thu, 22 Oct 2026 00:00:00 +0000

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 everything that has expired, which is a question over all the entries. In KvSQL both jobs run on one table.

db.execute("CREATE TABLE cache (key TEXT PRIMARY KEY, body BLOB, expires INTEGER NOT NULL);
            CREATE INDEX cache_expires ON cache(expires)", &[])?;

Store a response with put_row, which replaces an older entry under the same key:

Use Example: Settings Read by Key and Audited With SQL

Thu, 22 Oct 2026 00:00:00 +0000

Feature flags and settings are read all the time and listed rarely. The code asks “is the new checkout on?” on every request. Once in a while a person asks “what are all the search settings right now?” A plain keyspace in KvSQL answers both, with no schema at all.

Write settings as keys and values:

let mut tx = db.begin_write()?;
tx.put("settings", b"checkout.new_flow", b"on")?;
tx.put("settings", b"search.fuzzy", b"off")?;
tx.put("settings", b"search.limit", b"50")?;
tx.put("settings", b"upload.max_mb", b"20")?;
tx.commit()?;

Read one by key, straight from storage: