Developer preview v2026.07-1
The transactional document database for AI agents and apps.
Give every AI agent, tenant, or app its own logical database in a single cluster. One transaction still commits across all of them.
Apache 2.0 · Built on FoundationDB · RESP2/RESP3 wire protocol
one transaction · two databases · two models
BEGIN # An agent stores a memory, vector and all. NAMESPACE USE agents.support-bot BUCKET.INSERT memories DOCS '{"text": "prefers email", "embedding": [0.12, 0.07, 0.91]}' # Same commit bumps a shared usage counter. NAMESPACE USE billing ZINC.I64 support-bot:tokens 1240 COMMIT
Multi-model Bucket + ZMap Vector search built in Strictly serializable by default
Why Kronotop
Every AI agent and app needs its own data. Most stacks make you assemble it.
An isolated, transactional document database with built-in vector search, for every AI agent and app, on one cluster.
The usual tradeoff
✕
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 nobody runs thousands of real databases.
✕
Scaling out: horizontal scale is either hard to operate, or it means a third-party plugin or a separate product.
✓ The Kronotop model
A logical database is just a prefix in the keyspace, which Kronotop calls a namespace, so creating one is free. Each one is isolated by the prefix, not by application code, and millions run on one horizontally scalable cluster, with no plugins or separate products.
It is a full document database: BQL queries, secondary indexes, sorting. Vector search is built in, so similarity queries run on the same data without a separate engine. ZMap, an ordered key-value store, shares the same transaction. Commits are strictly serializable and span any namespace.
One transaction boundary
Many isolated databases and models.
One transaction.
Isolated databases are usually islands. Crossing them means two-phase commit, sagas, or eventual consistency. Kronotop keeps one commit across every namespace and across both data models, documents and ordered key-value, so writes either all land or none do, with conflict detection from FoundationDB.
Concepts
Document-focused, multi-model
Documents and an ordered key-value store share a transaction, with vector search over document fields.
In one query
Filter by structure, or recall by similarity
Find documents by what they contain, or by what they mean. BQL covers structured filters; vector search covers similarity.
// structured filter with BQL
BUCKET.QUERY
NAMESPACE USE agents.support-bot BUCKET.QUERY memories '{"importance": {"$gte": 0.5}}' 1# "cursor_id" => (integer) 1 2# "entries" => 1) {"_id": "...", "kind": "preference", "importance": 0.8, "text": "prefers email"}
// vector similarity + structured filter
BUCKET.VECTOR
BUCKET.VECTOR memories embedding '[0.10, 0.09, 0.88]' FILTER '{"kind": "preference"}' TOP 3 1) 1# "score" => (double) 0.9981 2# "entry" => {"_id": "...", "text": "prefers email"}
Wire protocol
No new driver.
No new mental model.
Kronotop speaks Redis wire protocol, so the client libraries and tooling you already use connect straight to it. Open a connection, encode BSON, run a document query, and read a RESP3 map back. Nothing new to learn.
import redis
from bson import encode as bson_encode, decode as bson_decode
# Connect to Kronotop using RESP3
r = redis.Redis(host="127.0.0.1", port=5484, protocol=3)
# Encode the filter to BSON and run BUCKET.QUERY
query = bson_encode({"user_id": "alice"})
res = r.execute_command("BUCKET.QUERY", "my_collection", query, "LIMIT", 10)
# Extract the cursor and document list from the RESP3 map
# RESP3 -> {"cursor_id": ..., "entries": [<bson>, ...]}
cursor_id = res[b"cursor_id"]
entries = res[b"entries"] or []
# Decode and print each raw BSON entry
for raw in entries:
doc = bson_decode(raw)
print(doc)Use cases
What people build on it
AI agents
Agent context store
Namespace-level isolation, vector search, and transactional updates for agent memory.
Documents
Transactional document store
A horizontally scalable document store backed by strictly serializable transactions.
Coordination
Distributed coordination
Lease-based locks with atomic acquire, safe release, and fencing tokens from versionstamped commits.
Key-value
Ordered key-value
Range scans, counters, and conflict-free atomic mutations on the ZMap model.
Get started
Spin up a local cluster
Copy two commands and you have a local cluster running.
bash
$ curl -O https://kronotop.com/kronotop-quickstart.yaml $ docker compose -f kronotop-quickstart.yaml up
Community