kronotop/kronotop

Kronotop – a distributed, transactional document store built on FoundationDB

What it is – Kronotop is a Java‑based database that stores JSON‑like (BSON) documents and ordered key‑value pairs. It runs on top of Apple’s FoundationDB, inheriting ACID, strict serializability, automatic sharding and fault‑tolerance. The service speaks the Redis/Valkey RESP protocol (both RESP2 and RESP3), so any existing Redis client can talk to it without a custom driver.

Why it matters for AI – The system is designed for workloads that need many isolated logical databases (called namespaces) – a common pattern for multi‑tenant AI platforms, per‑agent memory stores, or per‑user context caches. Each namespace is just a FoundationDB key‑prefix, so creating millions of them is cheap. Kronotop also offers:

• Vector indexes (via JVector) for approximate nearest‑neighbor search on embedding fields, enabling fast similarity look‑ups inside a transactional workflow.
• Cross‑namespace transactions – a single transaction can atomically read/write across any number of namespaces.
• Secondary indexes (single‑field, compound, and vector) and a rule‑based query planner that optimizes BQL queries.
• ZMap – a low‑level ordered key‑value API that maps directly to FoundationDB, exposing atomic mutations useful for counters, distributed locks, etc.

Core concepts

• Namespaces – hierarchical logical databases isolated at the key‑space level.
• Bucket – the document model; supports CRUD, BQL queries, cursor‑based streaming, and vector search.
• ZMap – a RESP‑compatible proxy for raw ordered key‑value operations.
• Transactions – thin wrappers around FoundationDB transactions; auto‑commit by default, with explicit BEGIN … COMMIT blocks for multi‑command atomicity.
• Clustering – data is sharded; each shard lives on a primary and optional standby Volume replica. FoundationDB handles all cluster coordination.

Typical use cases

• Per‑agent or per‑tenant context stores for LLM‑powered assistants, where each agent gets its own namespace and can store embeddings alongside other metadata.
• Horizontally scalable transactional document storage for applications that need strong consistency.
• Distributed coordination primitives (locks, counters) built on ZMap’s conflict‑free atomic mutations.
• Workloads that combine traditional key‑value access patterns with vector similarity search.

Maturity – The project is in developer preview. The core architecture and transaction model are stable, but APIs, internal formats and operational behavior may still change before a 1.0 release. Documentation is kept up‑to‑date, but occasional lag is expected.

Getting started

1. Install Docker and run the provided quick‑start compose file:

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

2. Connect with the bundled kronotop-cli (or any Redis client) to the client port (5484) for data operations and to the admin port (3320) for cluster management.
3. Create a bucket, insert a document, and query it using the RESP commands shown in the README.
4. For production use, build from source (Maven) or pull the pre‑built Docker image from GitHub Container Registry.

License – Apache License 2.0 (permissive, commercial‑friendly).

---

TL;DR – Kronotop is a FoundationDB‑backed, RESP‑compatible document database that gives you cheap, isolated namespaces, ACID transactions, and built‑in vector search – a handy building block for AI agents and other multi‑tenant, consistency‑critical applications.