Hey dev.to! 👋 This is my first ever post here, and I’m beyond excited to share a project I’ve been pouring my heart into: DBX - Database Extreme.
DBX is an embedded, multi-tenant vector and KV memory store designed specifically for autonomous AI agents. The big dilemma in AI agent architecture right now is how to store working memory and vector embeddings securely across hundreds of customers. Spinning up a heavy Firecracker microVM for every single user is too expensive, but just relying on tenant_id: 42 prefixes in a shared Redis instance is a security nightmare just waiting for a prompt-injection attack to leak cross-tenant data.
DBX solves this by taking the middle path: Hard OS-level process isolation at the cost of a single Goroutine.
I wanted to share exactly how our recent v1.1.0 (Isolation Kernel) and v1.2.0 (Vector Recall Cut) features performed when we threw a massive, concurrent stress test at them.
🛡️ The Architecture: Single Ingress, 100% Isolation
In our latest v1.1.0 upgrade, we completely overhauled how DBX handles multi-tenancy.
Instead of multiple ports or weak logical prefixes, DBX uses a Single Public Ingress Port (:6380). The control plane orchestrator multiplexes all incoming RESP requests, reads the identity from a specialized AUTH : command, and routes the TCP stream down to an isolated backend Unix socket.
Under the hood (on Linux), every tenant gets its own sealed dbx-server worker process protected by:
Linux Landlock LSM: The tenant process literally cannot open() a sibling tenant's directory.
Cgroups v2: Enforces strict memory and CPU boundaries so noisy neighbors can't crash the node.
Envelope Encryption: WAL bytes on disk are ciphertexts using per-tenant AES-256-GCM.
🚀 The Stress Test: 500k Strings & 250k Vectors
Architecture is just theory until it survives a stress test.
To validate the v1.2.0 quantized vector search upgrades, we ran a massive concurrency drill: 5 independent clients connecting to 5 isolated tenants at the exact same time, hammering the single multiplexer port with massive batch payloads.
The Payload per Tenant:
100,000 standard Key-Value strings
50,000 Dense Vectors (256-dimensional embeddings) batched in chunks of 1,000.
The Results:
The engine tore through the workload.
Aggregate KV Throughput: Exceeded 10,500 requests per second.
Aggregate Vector Ingestion: Reached nearly 2,000 dense vectors per second (across 5 isolated processes on a single local node).
Parser Optimizations: We had to optimize our custom Go RESP parser to handle arrays of over 4 million items to process the massive 4MB VADD_BATCH payloads being routed dynamically to the Unix sockets.
🎯 Accuracy Under Pressure
What good is fast insertion if the search recall drops?
As part of v1.2.0, DBX introduced optimized SQ8 (Scalar Quantization) and float32 index paths. The true test of a vector database is whether the HNSW graph can dynamically maintain its integrity while being aggressively mutated.
Immediately following the ingestion of the 250,000 vectors, all 5 clients simultaneously executed a live VSEARCH for the top 5 nearest neighbors.
Every single search returned the mathematically correct top-K matches instantly. The rate limiters (10,000 req/s bucket per connection) gracefully handled the burst without dropping connections, and the cgroup boundaries prevented any tenant from spiking host memory.
What's Next?
If you're building agentic workflows and you care about keeping your customers' reasoning chains completely sandboxed without breaking the bank on AWS bills, I’d love for you to check out DBX!
💻 GitHub: vanshjain-0702/DBX-Database-Extreme
I’m currently finalizing our async WAL replicas for instant per-tenant hot standbys. I’d love to hear your thoughts on multi-tenant architecture in the comments. Thanks for reading my first post!
Top comments (3)
First post and the isolation question is the right one to obsess over. We hit the same wall running a fleet of agents on shared infra: "lightweight namespace per tenant" sounds cheap until you audit what shares a heap with what.
Curious how DBX handles cross-tenant leakage on the vector side specifically — ANN indexes love shared memory segments for latency, and that is exactly where a bug becomes another tenant's embeddings. What failure story made you pick this line between the microVM and the embedded approach?
Spot on about shared memory! DBX avoids cross-tenant leakage by simply not using a global vector index.
Instead, every tenant has its own isolated .vec file. When a tenant wakes up, its isolated dbx-server worker process mmaps only its own file. Because we enforce Linux Landlock on that process, the OS kernel physically blocks it from opening or mmaping any sibling tenant's files. Zero shared memory segments across tenants.
The failure story that drove this: I was terrified of prompt injections tricking an agent into dropping a WHERE tenant_id = ? filter in a shared vector DB, leaking another customer's embeddings into the reasoning chain.
MicroVMs (like Firecracker) solve this but carry too much memory overhead for idle users. I wanted the hard boundary of a VM but the idle footprint of a Goroutine. Pinning an OS process with Landlock, Cgroups, and Unix Sockets was the perfect middle ground—idle cost sits at just ~15MB per tenant.
How is your team handling the agent infra scaling right now?
Some comments may only be visible to logged-in visitors. Sign in to view all comments.