KimmyDB

A JSON document database in Rust, built around three things that are usually awkward to get together:

• Change streams on a single instance. No replica set, no cluster, no ceremony. Start one container and subscribe to changes.
• Leaderless clustering. No primary, no elections, no quorum. Nodes gossip membership over SWIM and gossip state by anti-entropy — each contacts a few peers per round, pulls the oplog entries it is missing, and data reaches the whole cluster transitively. Discovery is DNS or a Kubernetes headless Service.
• AI-native storage. Embeddings are generated and maintained automatically per collection, and an MCP server runs inside the database so agents can query it directly.

📚 Full documentation is in docs/ — architecture, internals, API reference, operations, and the decision record.

Status: early development, released. Multi-user document CRUD, Mongo-style queries and aggregation, secondary indexes, live change streams over WebSocket, signed webhooks, automatic embeddings with vector and hybrid search, an in-process MCP server at /mcp, OIDC federation, and a versioned /v1 contract all work. Clustering works too — every node accepts writes, membership is SWIM and convergence is anti-entropy over the oplog; docker-compose.yml brings up three nodes. Pre-1.0: a minor release may break things and the changelog says so. See Roadmap.

Why it is built this way

The oplog is the spine. Every mutation appends one durable, HLC-ordered entry, and three subsystems consume that same log:

1. Change streams — WebSocket subscribers, resumable by token.
2. The embedding pipeline — an internal subscriber, which is why auto-embeddings need no separate scheduler.
3. Cluster anti-entropy — peers pull ranges they are missing.

Building the log once and reusing it three times is exactly why single-instance change streams work here. In MongoDB they are a byproduct of replication, so they require a replica set. Here the log exists whether or not the node has ever seen a peer.

Install

Releases are cut by tag. The server ships as a container image, and as a prebuilt Linux tarball.

# The server — multi-arch (amd64 + arm64) image on GHCR. Pick a root password
# and generate the signing key (32 bytes minimum): a container listens on
# every interface, and off loopback the node refuses an example's value for
# either secret rather than start with one everybody knows.
export KIMMY_ROOT_PASSWORD=$(openssl rand -base64 18)
docker run --rm -p 7878:7878 \
  -e KIMMY_ROOT_PASSWORD \
  -e KIMMY_JWT_SECRET="$(openssl rand -base64 32)" \
  -v kimmy-data:/var/lib/kimmy \
  ghcr.io/titusai-io/kimmydb:latest

Prebuilt kimmyd tarballs with SHA256 checksums — Linux arm64 and x86_64, statically linked against musl, so they run on any distribution — are on the