Five claims. One lifecycle.

Five claims. One lifecycle.

The tenant is a first-class object. Everything else — RESP, HNSW, the dashboard — is in service of that.

01

Tenant is a first-class object

POST /api/provision creates a live isolated engine: its own data directory, write-ahead log, HNSW index, snapshot lineage, and process-level state. Isolation is structural, not a naming convention.

Provision, back up, restore, and delete operate on exactly one customer. There is no cross-tenant scan and no shared keyspace to sweep.

Multi-tenant isolation deep dive →

02

State and memory in one engine

KV with TTL (session, scratchpad, rate counters) and HNSW vectors (semantic recall) live in the same process, behind one connection, in one data directory, and inside one backup archive. An agent’s session and its recall cannot drift apart — there is no second system to drift from.

Recall on that tenant is three commands: VSEARCH (query vector), VSIM (neighbors of a stored id, self excluded), and VFUSE (late-fusion across named SPACE graphs). Optional MIN_SCORE and per-query EF stay on the same wire. Embeddings stay with the caller; DBX does not run CLIP or MiniLM.

Honest limits: the periodic .rdb snapshot still serializes KV only. The tenant backup archive is the point-in-time unit: checksummed .rdb plus vector files, bound by seals that recovery verifies before WAL replay. Do not read that as “vectors live inside the .rdb.” VFUSE is a weighted sum of per-space cosine, not a multimodal model. Named spaces are extra mmap/HNSW files in the same tenant directory — backup, quota, and shred still hit one customer.

RESP-compatible KV + HNSW deep dive → · VFUSE late fusion deep dive →

03

Cost scales with active tenants

Vectors are stored as 8-bit scalar-quantized (SQ8) rows in an mmap’d file, with asymmetric distance computation at query time. Payload is roughly a quarter of float32. An idle tenant lives in page cache rather than resident RAM.

That is what makes hosting many small tenants viable. The metric is cost per active tenant — not the count of tenants you have signed.

SQ8 quantization and mmap density deep dive →

04

Self-hosted single binary

Embeddings never leave the customer’s network. The dashboard, console, data explorer, and vector playground are compiled into the same binary. No sidecar. No separate control-plane service to deploy. No vendor to send data to.

05

Isolation Kernel

On Linux production a tenant is a sealed execution domain: its own process, a Landlock-restricted view of the filesystem, and Unix sockets that only the orchestrator can open. The WAL, checkpoints, vector ids, and the HNSW graph are encrypted under a per-tenant key. Destroying that key makes what is left on disk unreadable without a scan.

Honest limits: SQ8 vector rows stay memory-mapped and unencrypted so idle tenants remain cheap — use fscrypt or LUKS for those. Data in use is plaintext inside the worker. Re-measured density under strict: ~14–17 MiB RSS per idle worker, worst idle GET ~3–12 ms. The in-process profile shares one process and is not this claim.

Operational upgrades

Change embeddings without losing the trail.

A

Shadow migration

VMIGRATE builds a target index on disk while the current index keeps serving reads. Stream caller-generated vectors, then promote the non-empty shadow index with an atomic lifecycle boundary. Cancel keeps the current index.

Re-embedding and transfer remain the caller’s work. The migration lifecycle is not yet a replicated WAL protocol.

Zero-downtime migration deep dive →

B

Historical vector search

VSEARCH ... AS_OF reconstructs retained vector WAL state for audit trails, RAG incident reproduction, and compliance investigations.

Historical search uses a temporary index, costs more than current search, and is limited by WAL retention.

Time-travel vector search deep dive →

On-ramp, not a USP

Your existing RESP clients work

DBX speaks RESP, so redis-py, ioredis, and go-redis connect without a custom driver. That lowers the cost of trying DBX. It is not a reason to choose DBX, and it is not a claim that DBX is a substitute for a tuned Redis cluster.

Completes USP 2 — not a sixth claim

Recall an agent actually issues

A product with per-customer memory needs more than “embed this string.” It needs neighbors of a stored memory, a score floor, and — when the caller already has two embedding spaces — a way to fuse them without standing up a second vector DB. All of that stays inside the tenant engine.

01

VSEARCH — semantic

Caller-provided query vector, cosine over HNSW, top-k last. Trailing MIN_SCORE, EF, SPACE, WITHDOCS, FILTER_CONTAINS.

02

VSIM — similar-to-id

Load that row, exclude self, same ANN. “More like this memory” without re-embedding. The id already lives in this tenant.

03

VFUSE — named spaces

Late-fuse cosine hits across SPACE graphs with caller WEIGHTS. Missing ids score 0. Send CLIP/SigLIP/MiniLM floats; DBX stores them. It does not run those models.

Certified ANN p50 on the published profile is 2.304 ms — not sub-millisecond. This is not hybrid sparse+dense search and not a Qdrant/Milvus competitor. It is the recall surface for one customer’s working set. Toy cosine in the browser: homepage recall bench.

The product

Tenant lifecycle

This is the API that defines the product. Everything else is a data-plane detail. Bearer token required on every call. Click through the sequence.

Provision an isolated engine

HTTP
curl -X POST http://localhost:8000/api/provision \
  -H "Authorization: Bearer $DBX_TOKEN" \
  -d '{"id": "acme-corp", "name": "Acme Corp"}'

replicas is optional (0–2). 0 is the certified single-node path. 1 or 2 starts async WAL replicas. The primary still acks writes locally; replica lag is possible.

Same token, same tenant id:

  • GET /api/v1/tenants/{id}/usage — keys, live vectors, memory, disk, commands. The meter a billing loop should call. Orchestrator GET /metrics is Prometheus text with per-tenant labels.
  • POST /api/tenants/export / import — aliases for backup/restore. SHA-256 manifest, rollback on a failed restore.
  • POST /api/v1/tenants/{id}/hibernate and /wake — stop a cold engine, keep the directory, rehydrate later. Sentinel will not restart a hibernated tenant.

New in v1.3.0 · Support and recovery

Diagnose and recover within a defined scope.

The separately installed support extension reads summaries for allowlisted tenants. An optional, distinct capability can wake a hibernated tenant with an audit trail and an independent health check.

  • Separate read and wake credentials, exact tenant allowlists, durable pre-action audit, and a server-enforced cooldown.
  • Local log scans and redacted incident bundles; 31 casebook entries, 43 support tests, and 1,340 repeatable synthetic drills.
  • Manually started and opt-in. Restore, deletion, configuration changes, and arbitrary bug repair stay outside the support capability.

Read the v1.3.0 announcement · Support API

Run it locally.