A transactional document database with a logical database per tenant, and one commit across all of them.
Proof: 1,000,001 namespaces created on one cluster →BEGIN # The tenant's own database: a new order. NAMESPACE USE tenants.acme BUCKET.INSERT orders DOCS '{"item": "keyboard", "qty": 2, "price": 49.99}' # A shared database, same commit: metered usage. NAMESPACE USE billing ZINC.I64 acme:requests 1 COMMIT
Kronotop gives each tenant or app an isolated database on one shared cluster. A transaction can cross any number of them.
Shared database: a tenant_id on every query. One missing filter leaks one tenant's data into another's.
Database per tenant: clean isolation, but few teams can run thousands of separate databases.
Scaling out: sharding a shared database by hand, or operating a fleet of small ones.
A logical database is a prefix in the keyspace, which Kronotop calls a namespace, so creating one costs almost nothing. Isolation lives in the keyspace, so application code carries no tenant filter. Millions of namespaces run on one horizontally scalable cluster.
Isolated databases usually cannot share a transaction. Crossing them means two-phase commit, sagas, or eventual consistency. In Kronotop one commit covers every namespace it touches and both data models, documents and ordered key-value. FoundationDB detects conflicts.
Each namespace is a full database: documents, an ordered key-value store, secondary indexes, and vector search.
BSON documents with a query language (BQL) and secondary indexes.
Key-valueFoundationDB's ordered key-value API over RESP: range scans, typed counters, atomic mutations, watches.
ConsistencyStrictly serializable by default, inherited from FoundationDB. Auto-commit or explicit BEGIN/COMMIT.
IsolationPer-tenant databases, called namespaces, with keyspace-level isolation on FoundationDB directories.
SearchApproximate nearest-neighbor search over document vector fields, built on JVector (HNSW).
OperationsSharded, distributed deployment with primary-standby replication.
BQL matches on field values. Vector search ranks by embedding distance.
Structured filter with BQL
NAMESPACE USE tenants.acme BUCKET.QUERY orders '{"qty": {"$gte": 1}}' 1# "cursor_id" => (integer) 1 2# "entries" => 1) {"_id": "...", "item": "keyboard", "qty": 2, "price": 49.99}
Vector similarity with a structured filter
BUCKET.VECTOR products embedding '[0.10, 0.09, 0.88]' FILTER '{"in_stock": true}' TOP 3 1) 1# "score" => (double) 0.9981 2# "entry" => {"_id": "...", "name": "Wireless Headphones"}
Kronotop speaks RESP2 and RESP3. The Python client, kronotop-py, exposes the Kronotop commands, manages sessions and transactions, and decodes BSON documents into dicts. From other languages, an existing RESP client such as node-redis sends the commands as they are.
# pip install kronotop-py
from kronotop import Kronotop
client = Kronotop() # localhost:5484
with client.session() as session:
session.bucket.create("orders", if_not_exists=True)
session.bucket.insert(
"orders",
{"item": "keyboard", "qty": 2, "price": 49.99},
)
# Documents come back as dicts, decoded from BSON
with session.bucket.query("orders", {"qty": {"$gte": 1}}) as cursor:
for doc in cursor.batch:
print(doc)import { createClient } from 'redis';
import { serialize, deserialize } from 'bson';
// Connect to Kronotop using RESP3
const r = createClient({ url: 'redis://127.0.0.1:5484', RESP: 3 });
await r.connect();
// Encode the filter to BSON and run BUCKET.QUERY
const query = serialize({ qty: { $gte: 1 } });
const res = await r.sendCommand(['BUCKET.QUERY', 'orders', query, 'LIMIT', '10']);
// Extract the cursor and document list from the RESP3 map
// RESP3 -> { cursor_id: ..., entries: [<bson>, ...] }
const cursorId = res.cursor_id;
const entries = res.entries ?? [];
// Decode and print each raw BSON entry
for (const raw of entries) {
console.log(deserialize(raw));
}Namespace-level isolation, vector search, and transactional updates for agent memory.
A horizontally scalable document store backed by strictly serializable transactions.
Lease-based locks with atomic acquire, safe release, and fencing tokens from versionstamped commits.
Range scans, counters, and conflict-free atomic mutations on the ZMap model.
Measured with Kronotop v2026.06-1 in June 2026, FoundationDB in single-redundancy mode on EC2. See the full results and deployment setup.
| 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 |
Copy two commands and you have a local cluster running.
Kronotop is in developer preview. The core architecture and transaction model are stable; APIs and internal formats may change before the first stable release.
$ curl -O https://kronotop.com/kronotop-quickstart.yaml $ docker compose -f kronotop-quickstart.yaml up