Kronotop
Kronotop is a distributed transactional document database that gives every AI agent or tenant its own namespace with built-in vector search.
Give a thousand agents their own database without running a thousand databases — that's the real product here, and it's the right shape for agent platforms and multi-tenant SaaS. Built-in ANN vector search on the same data means agent memory and structured state stop living in two systems. The honest caveat is maturity: developer preview v2026.10-1, self-hosted on FoundationDB, thin ecosystem. Prototype it if you can operate FoundationDB; don't put revenue on it yet.
Verified 4d ago · liveness 66/100 · cite: rightaichoice.com/tools/kronotop
- AI agent platforms giving each agent its own isolated, transactional memory store with vector search
- Multi-tenant SaaS needing per-tenant database isolation without provisioning thousands of instances
- Teams running transaction logic that spans multiple tenants or both data models
- FoundationDB users who want a document layer, BQL queries, and vector search on top
- Teams that need a fully managed cloud database with a vendor SLA
- Single-tenant apps where one Postgres instance with pgvector already does the job
- Production workloads requiring proven stability — this is developer preview v2026.10-1
We scan live Reddit threads, YouTube comments, X posts, G2 reviews and other communities — and hand you an honest verdict in under a minute.
- Honest verdict, not marketing
- Real pros & cons from real users
- Attributed quotes with receipts
3 free scans · no card needed
Skip Kronotop if you need a managed database with an SLA or your isolation and vector needs are already met by a single Postgres instance with pgvector — this is a self-hosted FoundationDB developer preview.
Because Kronotop is self-hosted, the real cost is operating a FoundationDB cluster plus Kronotop volumes and replication for it, not a license fee.
Kronotop is Apache 2.0 and self-hosted, so there is no per-seat or per-request bill — your spend is the compute and ops time to run FoundationDB plus Kronotop volumes. That puts it well below a managed multi-model database with vector support at scale, but above a single Postgres instance with pgvector for a small app, where the extra cluster is pure overhead.
In short
Kronotop — Kronotop is a distributed transactional document database that gives every AI agent or tenant its own namespace with built-in vector search. Best for AI agent platforms giving each agent its own isolated, transactional memory store with vector search, Multi-tenant SaaS needing per-tenant database isolation without provisioning thousands of instances, Teams running transaction logic that spans multiple tenants or both data models. Free to use.
What's new in Kronotop
Checked 3 days agoAcross the latest 2 updates: 1 launch and 1 news mention.
The .join() That Should Be a Bug
Engineering post on how Kronotop handles thousands of blocking connections on a single backend, covering the scalability engineering behind the cluster.
Kronotop developer preview is out!
Announces the first developer preview release, v2026.09-1, available via a Docker Compose quickstart that starts a minimal local cluster in two commands.
What people actually say about Kronotop — is it worth it?
We ran a structured research pass across product reviews, community discussions, and post-purchase forum threads to surface the patterns vendors won't publish themselves. Below: the recurring strengths, the hidden costs people mention most, and the cohort that consistently regrets adopting this tool.
14 mentions across 1 source (Hacker News) · researched Jul 3, 2026.
Average across the 1 source that answered — each source counts once, not each post.
- +Strictly serializable ACID transactions across multiple namespaces and data models.
- +Free and open-source under Apache 2.0 license with no enterprise pricing.
- +Built-in vector search without third-party plugins or separate services.
- +Redis RESP2/RESP3 wire protocol allows drop-in replacement for Redis clients.
- +Multi-tenant isolation via namespaces within a single cluster.
- −Very limited community feedback; mostly HN hype without real-world usage data.
- −Developer preview status implies potential bugs and backward compatibility risks.
- −No documentation on production deployment or scaling best practices.
- −FoundationDB operational complexity may deter teams without distributed DB ops.
- −Vector search performance and accuracy not benchmarked against alternatives.
- • Operational cost of running FoundationDB cluster (infrastructure + expertise)
Viability Score
How well maintained and how widely used is Kronotop? Built from what the vendor actually publishes (docs, changelog, tutorials, integrations, pricing), whether the site is live, and how much real users discuss it. How we calculate this
Last calculated: October 2026
How we score →Key Features
- Namespace isolation per agent, tenant, or app at FoundationDB directory keyspace prefixes
- Strictly serializable transactions spanning multiple namespaces in one commit
- Multi-model storage: document Bucket plus ordered key-value ZMap
- Built-in approximate nearest-neighbor (ANN) vector search via JVector HNSW
- Vector indexes with automatic Product Quantization; cosine, euclidean, dot_product distances
- BUCKET.VECTOR similarity search with structured FILTER clauses, TOP N
- BQL query language with comparison, logical, and array operators, dot notation, $elemMatch, regex
- Secondary indexes: single-field, compound, and vector
- Cursor-based streaming with BUCKET.ADVANCE, BUCKET.CLOSE, BUCKET.CURSORS
- ZMap typed numeric operations (int64, float64, decimal128) and conflict-free atomic mutations
- ZMap range operations: ZGETRANGE, ZDELRANGE, ZGETRANGESIZE, ZGETKEY, blocking ZWATCH
- Redis wire protocol RESP2/RESP3 support with existing Redis client libraries (Python, JavaScript)
- Auto-commit or explicit BEGIN/COMMIT/ROLLBACK transaction control
- Snapshot reads for read-heavy workloads (SNAPSHOTREAD, GETREADVERSION)
- Lease-based distributed coordination with atomic acquire, safe release, and fencing tokens
About Kronotop
Kronotop is a distributed, transactional document database built on FoundationDB. Its pitch is blunt: give every AI agent, tenant, or app its own logical database — a namespace — inside one cluster, and still let a single commit span all of them. A namespace is a prefix in the keyspace, so creating one is cheap and millions run on one horizontally scalable deployment. Isolation is enforced at the keyspace level rather than in application code, so you don't staple a tenant_id to every query and hope nobody drops a filter. The data model is multi-model. The document Bucket stores BSON documents with BQL queries, secondary indexes, compound indexes, and sorting. ZMap, an ordered key-value store, shares the same transaction with range scans, typed numeric operations (int64, float64, decimal128), and conflict-free atomic counters. Commits are strictly serializable by default with conflict detection inherited from FoundationDB, and snapshot reads are available for read-heavy workloads. Vector search is built in — approximate nearest-neighbor over document vector fields via JVector (HNSW) with automatic Product Quantization. You can rank by similarity and post-filter by structure in one call: BUCKET.VECTOR takes an embedding plus a FILTER clause of BQL predicates. The adoption shortcut is the wire protocol. Kronotop speaks Redis RESP2/RESP3, so existing Python and JavaScript Redis clients connect unchanged: open a connection, encode BSON, run a document query, read a RESP3 map back. It is Apache 2.0 and self-hosted, currently developer preview v2026.10-1, with a two-command Docker Compose quickstart. Positioning-wise, Kronotop collapses a document DB, a key-value store, and a vector engine into one transactional boundary — a shape Postgres with pgvector or MongoDB with Atlas Vector Search don't quite match. It is an independent project, not affiliated with Apple Inc. or Redis Ltd.
Behind the Verdict
If you already run FoundationDB, Kronotop is the cheapest experiment on your roadmap. Namespaces are prefix-based, so isolation costs effectively nothing, and one strictly serializable commit can touch a document in one namespace and bump a counter in another. The bundled example does exactly that — insert a memory, then ZINC.I64 a shared billing counter, then COMMIT. Pulling that off without two-phase commit or a saga is the whole argument. We'd reach for it when the problem is tenant (or agent) sprawl. Multi-tenant SaaS teams currently stuffing tenant_id into every query know the failure mode: one missed filter leaks data across tenants. Teams running thousands of per-tenant databases know the other failure mode: the operational weight. Kronotop sits between those, and it throws in vector search so you don't bolt on a separate engine. The Redis wire protocol is the part that actually shortens evaluation. Port 5484, RESP3, your existing Python or JavaScript Redis client, BSON in and a RESP3 map out. No new driver, no new mental model. Teams already comfortable with Redis tooling will have something running the same afternoon as the Docker Compose quickstart. Where it bites is operations and maturity. This is developer preview v2026.10-1, self-hosted, with no managed offering and a small community — Discord, GitHub Issues, a blog. FoundationDB is doing a lot of undifferentiated heavy lifting under the hood, which is good for correctness and bad for teams who have never run it. There's no SLA to point at when something goes sideways at 2 a.m. Pick it over Postgres with pgvector when you genuinely need per-agent or per-tenant isolation plus cross-namespace transactions plus vector recall in one place — that combination is awkward anywhere else. Pass on it for a
Researching Kronotop? Get your full AI stack in 60 seconds.
Free, no signup — tell us your goal and get tools matched to your budget & existing stack.
Real-world workflow fit
Concrete scenarios for the personas Kronotop actually fits — and what changes day-one when you adopt it.
You start a local cluster with the Docker Compose quickstart, connect an existing Redis client over RESP3, then NAMESPACE CREATE per agent and BUCKET.INSERT agent memories with embedding fields. A second command in the same BEGIN/COMMIT bumps a shared ZINC.I64 token counter in the billing namespace.
Outcome: Agent memory and usage accounting commit atomically across two namespaces, so a failed commit never leaves a stored memory without its billed tokens.
You create one namespace per tenant for isolation, then use BUCKET.QUERY with BQL filters for structured lookups and BUCKET.VECTOR with a FILTER clause for semantic recall over tenant documents, all through the existing Redis client library.
Outcome: Tenant isolation comes from the keyspace prefix rather than a tenant_id in application code, removing the class of bug where one missing filter leaks data across tenants.
You initialize a cluster with KR.ADMIN INITIALIZE-CLUSTER, inspect members and shards, configure Volume replication, and monitor with VOLUME.STATS opcounters and replication commands, scheduling VACUUM and changelog pruning.
Outcome: You keep the existing FoundationDB operational model and add a document layer, BQL, and vector search on top instead of introducing a separate vector database.
Use Cases
- Give each AI agent its own isolated document database with vector search in a single cluster.
- Run multi-tenant SaaS on one FoundationDB cluster with per-tenant namespaces, no tenant_id leaks.
- Combine document storage and ordered key-value counters in one strictly serializable transaction.
- Store agent memories with vector embeddings and update usage counters atomically in the same commit.
- Deploy a developer preview distributed document database for prototyping AI applications.
- Query documents by both structured BQL filters and semantic similarity using built-in vector search.
- Keep existing Redis client tooling while adopting a transactional document store.
- Serve read-heavy workloads with snapshot reads where strict serializability is not required.
Limitations
- Kronotop is at developer preview (v2026.10-2 shown on the site; the 2026-06-07 blog announced the first preview), and is not positioned for production use.
- It is built on FoundationDB and Apache 2.0, so deployment means self-hosting with FoundationDB operational knowledge; no managed cloud offering is documented.
- Interaction is through RESP2/RESP3 clients (e.g.
- Python, JavaScript Redis libraries) or the CLI/quickstart via Docker Compose rather than a graphical client.
- The ecosystem and community are nascent, with only a sparse blog (two posts as of mid-2026).
as of 2026-10-05
Verification history
We have re-verified Kronotop 10 times since . Each pass re-reads the vendor's own pages and re-checks every listed field against that evidence; passes where nothing had changed are marked as such.
- — re-verified summary, description, our verdict, our analysis, pricing model, pricing tiers, features, integrations, who it suits, who should skip it
- — re-verified summary, description, our verdict, our analysis, pricing model, pricing tiers, features, integrations, who it suits, who should skip it
- — re-checked, vendor evidence unchanged
- — re-verified summary, description, our verdict, our analysis, pricing model, pricing tiers, features, integrations, who it suits, who should skip it
- — re-checked, vendor evidence unchanged
- — re-verified summary, description, our verdict, our analysis, pricing model, pricing tiers, features, integrations, who it suits, who should skip it
Showing the 6 most recent of 10 verification passes.
Free to cite with attribution — this page re-verifies continuously.
12-month cost
Project the real annual outlay, including the implied monthly cost when only an annual tier is published.
Vendor list price only. Add-on usage, seat overages, and contract minimums are surfaced under Hidden costs & gotchas.
Plans compared
For each published Kronotop tier: who it actually fits, and what it adds vs. the previous tier. Cross-reference the cost calculator above for projected annual outlay.
Developer Preview
$0/mo
Ideal for
Infrastructure and platform engineers prototyping a multi-tenant or multi-agent data layer who can self-host FoundationDB and want to evaluate the multi-model engine without a license cost.
What this tier adds
Starting tier: Apache 2.0 self-hosted Kronotop, no license fee, with community support via Discord, GitHub Issues, and Releases.
Where the pricing makes sense
The company stage and team size where Kronotop's pricing actually pencils out — and where peers do it cheaper.
Kronotop is Apache 2.0 and self-hosted, so there is no per-seat or per-request bill — your spend is the compute and ops time to run FoundationDB plus Kronotop volumes. That puts it well below a managed multi-model database with vector support at scale, but above a single Postgres instance with pgvector for a small app, where the extra cluster is pure overhead.
Setup time & first value
How long it actually takes to get something useful out of Kronotop — broken out by persona, not the marketing-page minute.
For a developer with Docker: minutes to a local cluster via the two-command Docker Compose quickstart, then connect kronotop-cli or a RESP3 client and insert a first document. For a platform team standing up a real cluster: plan days, since you are provisioning and tuning FoundationDB, initializing the cluster, configuring Volume replication, and setting up monitoring before any application
Switching to or from Kronotop
How to bring data in from common predecessors and how to get it back out — written for the switcher, not the buyer.
- →From Redis: point your existing RESP2/RESP3 clients at Kronotop's port and swap string commands for BUCKET and ZMap commands as you move data out of plain keys.
- →From MongoDB-style document stores: map collections to Bucket and rewrite queries in BQL, reusing BSON-style document bodies.
- →From a separate vector database: move embeddings into document vector fields and replace external ANN calls with BUCKET.VECTOR in the same transaction as your writes.
- →From Postgres with a separate counter store: move documents into Bucket and counters into ZMap so both share one strictly serializable commit.
- ↗To Postgres with pgvector: export Bucket documents as BSON-shaped rows and embeddings into a vector column for single-tenant applications.
- ↗To a managed document database: dump Bucket documents per namespace and reload them, accepting loss of cross-namespace transactional commits.
- ↗To a dedicated vector database: extract vector fields from Bucket documents and rebuild an external ANN index.
- ↗To Redis: map ZMap keys back to plain Redis keys and re-encode document payloads outside Kronotop's BSON-on-RESP3 format.
Resources & Guides
Tutorials & Learning
YouTube returned 4 videos for “Kronotop”, and we withheld 4: 4 could not be judged, because “Kronotop” is a single word that other videos use for other things. We are showing none, because we could not prove any of them are about Kronotop.
Official links
Tools that pair well with Kronotop
Common stack mates teams adopt alongside Kronotop, with the specific reason each pairing earns its keep.
Tidb
TiDB is a distributed SQL database for AI agents that unifies ACID transactions, HTAP analytics, and native vector search in one engine.
Pinecone
Pinecone is a managed vector database and knowledge engine for RAG, semantic search, and agent retrieval.
RAGFlow
Open-source RAG engine with built-in ETL, hybrid vector/BM25 search and visual agent orchestration for enterprise AI agents.
Featured Head-to-Head Comparisons
Kronotop vs Spider Cloud
Choose Kronotop if you need a distributed, transactional document database with built-in vector search and per-tenant namespace isolation—ideal for AI agent backends. Choose Spider Cloud if you need fast, reliable web crawling and scraping for RAG pipelines, with recent additions like Browser AI commands and data connectors. They solve different problems; evaluate based on whether your core need is storage or data ingestion.
Kronotop vs Voyage Ai
Kronotop and Voyage AI serve different layers of the AI stack. Kronotop is a free, self-hosted database that bundles vector search with strong transactions, ideal for multi-tenant AI agent platforms in developer preview. Voyage AI is a managed API for embedding and reranking, best for enterprises needing domain-specific retrieval accuracy. Choose Kronotop if you need an all-in-one storage and search solution; choose Voyage AI if you need top-tier embeddings with any vector database.
Kronotop vs Temporal Ai
Kronotop and Temporal AI solve different problems: Kronotop is a distributed database with vector search for per-agent storage, while Temporal is an orchestration engine for durable workflow execution. For a team building AI agents that need both persistent memory and reliable orchestration, combining both tools could be ideal, but most buyers should choose based on whether their primary need is data storage or workflow reliability. Kronotop is free and developer preview, offering innovative multi-tenant storage; Temporal is mature with a freemium cloud option, trusted by major AI companies.
Alternatives to Kronotop
View all
Frequently Asked Questions
Used Kronotop? Help shape our editorial sentiment research.