I Built an Isolated Multi-Tenant AI Memory DB: Here's What Happened Under Massive Load

Vansh Jain — Fri, 11 Sep 2026 10:16:56 +0000

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!

DEV Community: Vansh Jain

I Built an Isolated Multi-Tenant AI Memory DB: Here's What Happened Under Massive Load