acme
session empty
vectors 0
WAL seq 0
Memory engine, not a shared cluster.
One isolated engine per customer.
DBX holds working state and vector memory in the same process — and that process belongs to one tenant. Isolation is a directory, a WAL, and an HNSW index. Not a prefix you hope nobody forgets.
- Isolated engines
- RESP :6380
- 100 tenants / node
- BSL 1.1
Isolation · in-browser
harbor
session empty
vectors 0
WAL seq 0
lumen
session empty
vectors 0
WAL seq 0
Browser sketch of the product, not a live node. GET on harbor cannot see acme’s session.
Why it exists
Shared clusters make tenancy your job.
The stores you already run assume one pool. You bolt customers on with names. That works until it doesn’t.
-
01
Tenancy is a key prefix
One missing
tenant:{id}:in one query is a cross-customer data leak. -
02
Two systems drift
Session in a cache, embeddings in a vector DB. Dual writes. Two pages at 3am.
-
03
Backup is cluster-wide
You cannot restore one customer. You snapshot the whole machine.
-
04
Delete-my-data is a sprint
A scan, a prefix sweep, a blast radius. Off-boarding becomes a project.
-
05
Noisy neighbor eviction
One busy tenant evicts a quiet tenant’s working set from a shared pool.
What has to stay true in the code
The tenant is the unit of everything.
Five claims. RESP is how you connect, not why you buy.
01
Tenant is a first-class object
POST /api/provision creates a live isolated engine — own data directory, WAL, HNSW, snapshots. Backup and delete hit exactly one customer.
02
State and memory in one engine
KV with TTL and HNSW vectors, one process, one connection, one directory, one backup archive.
03
Cost scales with active tenants
SQ8 mmap vectors. Idle tenants sit in page cache. You pay for who is awake, not who signed.
04
Self-hosted single binary
Dashboard, console, explorer, playground — compiled in. Embeddings never leave the network.
05
Isolation Kernel
Linux production seals each tenant as its own process with a Landlock-restricted filesystem, an encrypted WAL and index, and a Unix socket only the orchestrator can open.
redis-py, ioredis, go-redis already speak RESP. Useful for trying DBX. Not a substitute for a tuned shared KV cluster.
Operator UI, in the binary
This is the console you actually get.
Not a mock. Screens from the embedded dashboard: tenants, overview, and the RESP console.
Fit
Who it is for. Who it is not.
Build this if
- AI agent platforms — each end-customer’s agent needs private recall
- Vertical AI SaaS — legal, medical, support, finance RAG per client
- On-prem / regulated — one binary inside their network
- Teams tired of running a cache and a vector DB
Walk away if
- One tenant, one workload
- You need billion-vector ANN, sharding, or heavy filtering
- You want a fully managed vector service with no infrastructure
- You need SQL, joins, or a system of record
| If you need | Use | Why not DBX |
|---|---|---|
| Peak shared KV throughput | Redis / Dragonfly | Their design target. Ours is isolation. |
| Billion-vector ANN | Qdrant / Milvus | DBX is sized for per-tenant working sets. |
| Fully managed vectors | Pinecone | DBX is software you run. Deliberately. |
| System of record | Postgres + pgvector | DBX sits in front of the system of record and underneath the agent. |
Operator walkthrough
The dashboard, frame by frame.
Real screens from the embedded UI. No stock footage. Advance with the arrows or sit with the loop.
BSL 1.1
Install it in your rack. Measure it on your hardware.
Free to self-host, including inside your own SaaS. Cannot offer managed DBX to third parties without a commercial deal.