OLTP database engine

Invariants live in the engine.

KDBS narrows its surface to what online transaction processing needs — keyed access, short transactions, predictable latency — and spends what that buys on the rules your data must obey.

Try it in the browser What the engine guarantees

kdbs sandboxSQL

kdbs> CREATE ASSERTION purchase_limit ON purchases  GROUP BY (user_id, product_id) CHECK COUNT(*) <= 3;CREATED ASSERTION name=purchase_limit enforcing=1kdbs> INSERT INTO purchases VALUES (1, 7, 100, 'fourth');ERR ASSERTION_VIOLATION assertion "purchase_limit"group (user_id=1, product_id=7): COUNT(*) wouldexceed bound 3kdbs> DELETE FROM accounts WHERE id = 3;DELETED 1kdbs> INSERT INTO accounts VALUES (3, 'dave', 1);                                   ^ERR duplicate primary key 3: a row with this keywas deleted; a Keystone id is bound once

Guarantees

Declared once in the schema. Enforced for every writer.

No duplicate ids, no group over its limit, no retry that runs twice: enforced by the engine rather than in each service, these hold for every writer, whether a service, a script or an agent.

Identity that never lies

A row's primary key is its identity, bound to it for the life of the table.

Pros

The database issues each new row an id that has never been used in that table.
Deleting a row does not free its id; only an explicit PURGE does, so an old reference never silently points at a new row.
A primary key cannot be changed; an UPDATE that tries is refused.

Rules checked before every write

Declare a rule once in the schema; the engine checks it before every write.

Pros

Limits per group, such as "at most 3 orders per customer and product" or "spend at most 1,000 per user", using standard CREATE ASSERTION.
Each check is a constant-time lookup, however much data the group already holds.
Foreign keys: a row cannot reference a parent that does not exist.

Behavior you can predict

What the engine learns changes how fast a query runs, never what it returns.

Pros

The engine adds shortcuts for queries it sees often. Removing every shortcut leaves every answer unchanged.
A query keeps the same execution plan as the data grows, so its cost does not jump unexpectedly.
Each transaction chooses how durable its commit is, and the possible loss is stated for each choice.

Design philosophy

Every constraint is a capability given up for a guarantee.

Built for OLTP, not general use

Keyed access, equality joins, subqueries, pagination and short transactions. Statements compile to step chains run in written order, so the query is the plan.

The engine observes, then reorganizes

Executions feed decaying statistics. The physical optimizer builds and retires lookup structures, changing what exists, not just how queries run.

Advisory by construction

Delete everything the engine has learned and queries return the same rows, only slower. The B+ tree is the sole unconditional authority, a hard invariant with its own tests.

Reliability is a feature

One write-ahead log per instance, durability set per transaction, page checksums, full page images, recovery at mount and deterministic fault injection.

One thread per core

One cooperative reactor per core over shared memory. Statements finish on their session's core, and asynchronous I/O behind an injectable seam lets the engine run under deterministic simulation.

Truthfulness beats convenience

Every refusal carries the offending token's byte position. Unsupported means understood and declined, InvalidArgument means simply wrong.

The trust ladder

Four structures share the access path, each trusted to a different degree.

Structure	Authority	Write cost	Droppable	A failed entry means
Clustered pk B+ tree	Always authoritative	Updated on write	Never	Corruption
Secondary index	Authoritative, full coverage	Appended on write	Wholesale (DROP INDEX)	Statement failure
Cabin	Authoritative for observed values	Probe and append, observed values	Per value	Unobserve, then scan
Waystone trail	Never authoritative (advisory)	None on writes	Wholesale	Fallback to authoritative path

Keystone

Each tuple begins with a 64-bit Keystone word: a 48-bit id (≈2.8 × 10¹⁴ per relation) and status bits. The id is identity, not a field: an UPDATE naming it is refused at compile time.

Waystone

From a query's second run, the engine records the rows it touched and replays that trail, validating every entry. A trail may replace a lookup, never a search.

Cabin

One store per column tracks only the values queries asked for, and only there is it authoritative. An observed value's empty set is an authoritative "no rows". Un-observing is always legal.

Architecture

One execution model, on every core.

Clients speak KWP/1, a binary protocol. Statements compile at parse time into step chains run on the session's core. Trails and Cabins sit beside an authoritative B+ tree, over one WAL stream and one growable file.

Select a component to open its documentation.

Run a query against a real instance.

The sandbox connects you to a live KDBS server with sample tables and assertions already loaded.

Open the sandbox