Kronotop: a distributed, transactional document database built on FoundationDB<br>Skip to content

BEGIN<br>COMMIT

Bucket<br>documents<br>ZMap<br>key-value

FoundationDB<br>strictly serializable · automatic sharding

Millions of databases. One transaction.<br>Developer previewv2026.06-3 Give every tenant, AI agent, or workspace its own namespace, then commit across all of them atomically.

Quickstart Why Kronotop? GitHub

Apache 2.0 · Built on FoundationDB · Speaks RESP

Atomic across models<br>Section titled “Atomic across models”

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

One transaction, two modelsBEGIN

# 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 BQLNAMESPACE 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}

(integer) 12# "entries" => 1) {"_id": "6a133c8806bf494c9e7e00cb", "item": "keyboard", "qty": 2, "price": 49.99}">

A namespace per tenant<br>Section titled “A namespace per tenant”

A namespace is a lightweight logical database, just a FoundationDB directory<br>prefix, so creating one costs nothing and adds zero runtime overhead. Run many<br>of them on one cluster, and a single transaction can still commit across any of<br>them.

Why Kronotop?<br>Section titled “Why Kronotop?”

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

Kronotop removes the workaround: FoundationDB’s consensus and conflict detection<br>handle the atomic commit, so your application coordinates nothing.

The same boundary scales to tenants. Instead of provisioning a database per<br>customer or enforcing isolation in application code, each tenant, AI agent, or<br>workspace gets its own namespace at no extra cost.

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

Kronotop speaks RESP, so it works with the RESP-compatible clients you already<br>use.

Core concepts<br>Section titled “Core concepts”

Bucket Document model storing BSON, with a query language (BQL), secondary indexes, and sorting.<br>ZMap Ordered key-value model with range scans and conflict-free atomic counters.<br>Transactions Strictly serializable by default, inherited from FoundationDB. Auto-commit or explicit BEGIN/COMMIT.<br>Namespaces Lightweight logical databases with keyspace-level isolation, built on FoundationDB directories.<br>Vector search Approximate nearest-neighbor search over document vector fields, powered by JVector (HNSW).<br>Clustering Sharded, distributed deployment with primary-standby replication, where coordination is handled by FoundationDB.

Use cases<br>Section titled “Use cases”

AI agent context store<br>Namespace-level isolation, vector search, and transactional updates for agent memory.

Transactional document store<br>A horizontally scalable document store backed by strictly serializable transactions.

Distributed coordination<br>Lease-based locks with atomic acquire, safe release, and fencing tokens from versionstamped commits.

Ordered key-value<br>Range scans, counters, and conflict-free atomic mutations on the ZMap model.

Benchmarks<br>Section titled “Benchmarks”<br>Read-only Bucket queries against 50,000 documents, with FoundationDB in<br>single-redundancy mode on EC2:<br>23,008queries/sec, sorted reads<br>2.88 msp99 latency

QueryThroughputp99Indexed equality11,751 qps6.12 msCompound index11,082 qps6.49 msSort + limit 1023,008 qps2.88 msFull scan (unindexed)1,958 qps50.02 ms<br>See the full benchmark results and deployment setup for the complete table.

Get started<br>Section titled “Get started”<br>Spin up a local cluster (one FoundationDB node, one Kronotop primary, and one<br>standby) with Docker Compose.<br>Terminal windowcurl -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.<br>Community<br>Section titled “Community”<br>Kronotop is developed in the open.<br>Discord Ask questions, share feedback, and follow development.<br>GitHub Issues Report bugs and propose ideas.

FoundationDB is a trademark of Apple Inc. Kronotop is an independent project and is<br>not affiliated with, endorsed by, or sponsored by Apple Inc.