One transaction, multiple models

Apache 2.0 · Built on FoundationDB

Atomic across models

A single transaction can write a document and update a counter across isolated namespaces, atomically:

One transaction, two models

BEGIN

# In the sales namespace: record a new order.
NAMESPACE USE production.sales
BUCKET.INSERT orders DOCS '{"item": "keyboard", "qty": 2, "price": 49.99}'

# In the inventory namespace: decrement stock, conflict-free.
NAMESPACE USE production.inventory
ZINC.I64 keyboard -2

COMMIT

Read it back with BQL

NAMESPACE USE production.sales
BUCKET.QUERY orders '{ "qty": { "$gte": 2 } }'
1# "cursor_id" => (integer) 1
2# "entries" => 1) {"_id": "6a133c8806bf494c9e7e00cb", "item": "keyboard", "qty": 2, "price": 49.99}

Why Kronotop?

When an application uses separate systems for documents, queues, key-value data, and counters, each one has its own consistency model and failure modes. They share no distributed commit protocol like 2PC or XA, so there is no atomic write across them; the workarounds are retry loops, outbox tables, and saga coordinators.

Kronotop places multiple data models behind one transaction boundary. Consensus and conflict detection come from FoundationDB, so a single transaction can atomically span the Bucket and ZMap models across namespaces without any application-level coordination.

FoundationDB has a decade of production use and is validated with deterministic simulation testing.

Core concepts

Bucket Document model storing BSON, with a query language (BQL), secondary indexes, and sorting.

ZMap Ordered key-value model with range scans and conflict-free atomic counters.

Transactions Strictly serializable by default, inherited from FoundationDB. Auto-commit or explicit BEGIN/COMMIT.

Namespaces Lightweight logical databases with keyspace-level isolation, built on FoundationDB directories.

Vector search Approximate nearest-neighbor search over document vector fields, powered by JVector (HNSW).

Clustering Sharded, distributed deployment with primary-standby replication, where coordination is handled by FoundationDB.

Use cases

AI agent context store

Namespace-level isolation, vector search, and transactional updates for agent memory.

Transactional document store

A horizontally scalable document store backed by strictly serializable transactions.

Distributed coordination

Lease-based locks with atomic acquire, safe release, and fencing tokens from versionstamped commits.

Ordered key-value

Range scans, counters, and conflict-free atomic mutations on the ZMap model.

Benchmarks

Read-only Bucket queries against 50,000 documents, with FoundationDB in single-redundancy mode on EC2:

23,008queries/sec, sorted reads

2.88 msp99 latency

Query	Throughput	p99
Indexed equality	11,751 qps	6.12 ms
Compound index	11,082 qps	6.49 ms
Sort + limit 10	23,008 qps	2.88 ms
Full scan (unindexed)	1,958 qps	50.02 ms

See the full benchmark results and deployment setup for the complete table.

Get started

Spin up a local cluster (one FoundationDB node, one Kronotop primary, and one standby) with Docker Compose.

curl -O https://kronotop.com/kronotop-quickstart.yaml
docker compose -f kronotop-quickstart.yaml up

Full quickstart → Connect with kronotop-cli, create a bucket, then insert and query your first document.

Community

Kronotop is developed in the open.

Discord Ask questions, share feedback, and follow development.

GitHub Issues Report bugs and propose ideas.