Now onboarding design partners · 2026

State for a
million agents.

Give every AI agent its own database — isolated, forkable, and buried in object storage for pennies. Millions of namespaces, scale-to-zero, no corruption under load. Source-available and self-hostable.

No spam. We reach out when a slot opens for your stack.

↓ descend through the storage tiers
The problem

One agent is easy. A million is a patchwork.

Platforms running fleets of agents duct-tape four systems together just to give each one memory and state — and every one fights the "millions of tiny tenants" shape: RAM-priced, corrupts under concurrent writes, no scale-to-zero, and locked to a managed vendor.

Redis · RAM $$$ Vector DB · index can corrupt under concurrent writes Postgres · scale-to-zero breaks Neo4j · one more system to run
● Hot tier — RAM · <10 ms

The working set stays warm.

Active agents' vectors and state live in RAM, so warm queries return in single-digit milliseconds — competitive with any in-memory database, without keeping everyone in memory.

<10ms
warm query, p50
● Warm tier — NVMe SSD · 10–50 ms

Recently-touched data cascades down.

As agents go quiet, their data slides from RAM to local NVMe — still fast, a fraction of the cost. The cache decides what's hot; you never provision per tenant.

$0.60
per GB · SSD tier
● Cold tier — bedrock — S3 / R2 / GCS · the source of truth

Idle agents rest in object storage — for pennies.

Every namespace's durable home is object storage at ~$0.02/GB. Idle agents cost almost nothing; a cold first-touch re-warms in about a second. This is why a million agents is affordable.

$0.02
per GB stored · idle namespaces ≈ free
What you get

Four primitives, built for fleets.

Namespace = tenant

A database per agent

Millions of isolated namespaces on one cluster. Adding a tenant never slows down the others — a namespace is just an object-storage prefix.

Scale-to-zero

Idle costs nothing

Agents are idle ~99% of the time. Theirs falls to cold storage and stops billing compute — no warm RAM sitting idle.

Copy-on-write fork

Branch a mind in ~500 ms

Fork an agent's entire state to explore parallel reasoning paths, then time-travel or roll back. Metadata-only, near-instant.

Correct under load

No silent corruption

One writer per namespace + batched commits means massive parallel writes can't corrupt the index or lose memories — correct by design.

See yourself

Which one are you?

Pick your setup — here's exactly where BurrowDB fits, and the call you'd actually make.

State that outlives the VM

You run coding agents in ephemeral VMs or sandboxes — each one spins up, works a repo, and tears down.

Re-indexing the whole codebase on every fresh VM is slow and wasteful — and the state dies with the box. One namespace per repo lives in object storage. A new VM re-attaches instantly; the index and memory outlive the VM.
re-attach, don't re-index · $0 while idle 
# fresh VM boots → re-attach the repo's state, no re-index
POST /v1/ns/repo:acme-api/query
  { vector: embed("where is auth handled?"), top_k: 8 }
→ 8 code chunks · 9 ms warm · $0 while the VM slept

A memory per agent — fork to explore

You run fleets of agents, each with its own memory, often trying several approaches at once.

Per-agent memory glued across Redis + a vector DB + Postgres corrupts under concurrent writes. A namespace per agent, plus copy-on-write fork for parallel reasoning paths — correct under load.
fork in ~500 ms · no corruption under fan-out 
POST /v1/ns/agent:7f3/upsert  { docs:[…], vectors:[…] }
POST /v1/ns/agent:7f3/fork   { new_ns: "agent:7f3@branch-A" }
→ forked in 480 ms · explore 5 paths in parallel · keep the winner

Millions of apps, pay for the active few

You generate millions of apps; each needs its own backend state, and most of them sit idle.

A database per app blows up cost — you pay for apps nobody opened this month. A namespace per app, scale-to-zero. Idle apps fall to object storage and cost almost nothing.
millions of tenants · pay for active only 
POST /v1/ns/app:9d21/upsert  { kv:{ prefs:… }, vectors:[…] }
# 4,000,000 generated apps · ~2% active this week
→ idle app ≈ $0.001/mo · active served <10 ms warm

In your cloud, erasable on demand

Your agents work on sensitive data that legally can't leave your cloud.

Managed vector vendors mean your data leaves your VPC — a compliance non-starter. Self-host BurrowDB in your own VPC (BSL). Per-record crypto-shred erasure for GDPR.
in your VPC · GDPR-ready erasure design · SOC 2 on the roadmap 
# runs entirely inside your VPC — your bucket, your keys
POST /v1/ns/case:8842/erase  { subject: "user:123" }
→ key shredded <30 s · physical purge ≤7 d · audit certificate
Where we fit

Not the flashiest vector DB. The one you can actually run.

Built for how agents think

Isolated per-agent memory, copy-on-write fork, and time-travel — state as a first-class control-loop primitive, not a bolted-on index.

One layer, not four

Vector + key-value + memory in a single store — retire the Redis + vector-DB + Postgres patchwork.

Cheap where it counts

Object-storage economics for storage and mostly-idle tenants (write cost scales with commit rate).

Yours to run

Managed cloud, or self-host in your own VPC — source-available and cross-cloud.

We're honest about it: BurrowDB is for teams running fleets of agents who've outgrown the Redis + vector-DB + Postgres patchwork and want unified, forkable agent state — on our managed cloud or self-hosted in your VPC. Cheapest for storage and mostly-idle tenants; high-write workloads are priced by commit rate, not magic. If you run one agent on a managed vector service and it's fine, you don't need us yet.

Where we fit

Three layers. We own the one agents act on.

The AI data stack isn't a cage match — it's layers. Analyze, search, act. BurrowDB is the operational memory every agent runs on; the other layers sit above it.

Analyze Understand what your agents did — traces, evals, metrics, dashboards. ClickHouse · Langfuse
Search Retrieve knowledge and context to feed a prompt. Turbopuffer · vector DBs
● Act · state Give every agent its own live, isolated, forkable memory to act on. BurrowDB

Complementary, not competitors: analytics engines analyze, search engines retrieve — BurrowDB is the operational state agents run on, a layer built for millions of tiny live tenants that the others' architectures aren't.

Early access

Give your agents a home.

We're onboarding a small group of design partners building agent, coding-agent, and sandbox platforms. Tell us where to reach you.

Design partners get white-glove migration and pricing.