Docs

Architecture

Every tenant gets its own isolated in-memory store: KV working state and HNSW-indexed vector memory, with its own WAL and snapshot lineage. The orchestrator owns lifecycle; each tenant owns its data.

The wire protocol is RESP2-compatible so existing clients connect without a custom driver. That is an on-ramp, not a claim that DBX substitutes for a tuned shared KV cluster. See positioning.

Orchestrator

cmd/dbx-orchestrator is the control plane: JWT auth, provision / promote / backup / restore / export / import / hibernate / wake / delete, per-tenant usage, Prometheus GET /metrics, one public RESP ingress on :6380, and reverse-proxying to the current primary. Data-plane Raft and cluster mode fail closed. Sentinel does not restart a hibernated tenant.

Because each tenant owns a separate directory, every lifecycle operation affects exactly one customer.

Tenant server

cmd/dbx-server is the data plane. One instance per tenant member. On Linux production (DBX_ISOLATION_MODE=strict) that instance is a sealed worker process: Landlock, cgroup, envelope-encrypted files, Unix sockets with SO_PEERCRED. See the Isolation Kernel in the repo docs.

Request path

  1. RESP ingress requires AUTH tenantID:keyID secret.
  2. The scoped credential is verified and the command is routed to that tenant’s loopback listener.
  3. The key is re-resolved on every command so revocation is immediate.
  4. The tenant engine enforces role and key patterns, appends a WAL v2 transaction, acks locally, then applies.

Persistence

  • WAL v2 — length-framed, sequenced, CRC-protected. always fsyncs before ack; everysec is a one-second loss window.
  • Checkpoints — sequence-bearing KV snapshots. Vector rows live in mmap files, not in the periodic .rdb image. Do not claim a single atomic KV+vector snapshot.
  • Backup — maintenance lock, SHA-256 manifest, restore into a sibling directory with rollback. Export/import are aliases. Hibernate stops the engine and keeps the directory; wake rehydrates it.
  • Density — CI soaks 12 idle / 4 active engines. Operators run make soak for 100 idle / 25 active. That is not a 100-orchestrator-process soak. The Isolation Kernel’s strict profile is a security mode, not that density drill.

Isolation Kernel

Linux production (DBX_ISOLATION_MODE=strict) seals each tenant as its own process with a Landlock-restricted filesystem view, per-tenant AES-256-GCM over the WAL, checkpoints, vector ids and HNSW graph, and Unix sockets that only the orchestrator PID can open.

Limits worth stating: SQ8 rows stay mmap'd and unencrypted so idle tenants stay in page cache — use fscrypt or LUKS for row confidentiality. Landlock covers file opens, not connect(); peer credentials stop cross-tenant sockets. cgroup limits require a host that delegates cgroup writes. Data in use is plaintext inside the worker. inprocess is the default density/dev profile and is not the security claim.

Dashboard

React UI compiled into the orchestrator binary. Tenant keys (/cluster/{id}/keys) mints reader/writer/tenant-admin credentials; the secret is shown once. Console, explorer, and vector playground use an operator JWT on :8000. They are operator tools, not the public tenant API.

Public site

Static HTML in website/. Live: dbxdb.co.in. Local preview: make site. See website/README.md.