Case study 15 / 26

TesseraDB

An embedded SQL database where the past is a first-class query: every row version retained, AS OF reads, and event streams in the same transactions.

Status: Research
Period: 2026
Domain: tools · experiments
Language: Rust
Last push: 05 SEP 2026
License: MIT
Source of claims: README.md, ARCHITECTURE.md, tests/recovery.rs

tessera app.dbREADME EXAMPLE

UPDATE task SET state = 'running' WHERE id = 7; -- txn 3

UPDATE task SET state = 'failed' WHERE id = 7; -- txn 4

APPEND TO audit 'task 7 failed: timeout';

tessera> SELECT state FROM task WHERE id = 7;

failed

tessera> SELECT state FROM task AS OF TXN 3 WHERE id = 7;

running

tessera> HISTORY task WHERE id = 7;

-- all three versions, with xmin/xmax

tessera> READ audit SINCE 0;

-- seq, txn, value

pagesWALMVCCplanner

01/The problem

Most embedded databases treat history as the application's problem — updated_at columns, audit tables and triggers that drift. Systems that do version rows are large servers or JVM runtimes. Agent and workflow systems need to ask what the world looked like when a decision was made, and correlate it with a stream of things that happened.

02/The system

A single-file, zero-dependency relational engine in Rust. Rows are never overwritten, so any query can be asked as of an earlier transaction, and append-only event streams share the write-ahead log and the commit with your tables.

03/Implementation

01Temporal by default: AS OF TXN n reads any past snapshot; HISTORY shows every version of a row with the transactions that created and ended it.
02Event streams: APPEND TO / READ … SINCE are transactional, durable and ordered — and roll back with the tables written beside them.
03Optimistic MVCC with an (xmin, xmax) visibility model: readers never block; conflicting concurrent writes fail loudly at COMMIT.
04A slotted-page file format with overflow chains, a checksummed WAL with idempotent replay, and atomic page-file replacement at checkpoint.
05Secondary indexes the planner uses for UPDATE and DELETE as well as SELECT; usable as a library (Send + Sync) or through a REPL.

04/Engineering

Every commit is a snapshot

There is no versioning flag — time travel is how the storage works. Snapshot ids are transaction ids, so an event's txn column joins directly to the table state it was written with.

Torn-write-safe by construction

Every WAL frame carries a CRC; recovery replays up to the first bad frame and discards the rest. Recovery tests kill the database's view without checkpointing and assert on what comes back.

No dependencies, not even for CRC

About 2.5k lines in one crate — auditable end to end, and readable in an afternoon.

05/Interface

No product screenshots are published for this project. The visual above is a code-driven representation of how it behaves, built from the repository source — not a screenshot.

06/Tech stack

Rust (edition 2024)
Zero dependencies
WAL + CRC
MVCC
Fuzz testing

07/Result

Verified outcomes

Unit, integration, recovery, concurrency and fuzz suites (random token soup and random WAL bytes).
Reported in the README (one run, laptop NVMe): ~833k primary-key lookups/s; ~487k inserts/s inside one transaction; 50k-version AS OF scans at ~5.8k scans/s.

Known limitations

0.1 research-grade: the whole database is memory-resident; no joins, aggregates beyond COUNT(*), GROUP BY or ALTER TABLE.
History is not garbage-collected yet; no file lock across processes.

08/Links

GitHub repository ↗

Next case study

Halyard →