Millions of backends per server

One of our core claims is that a single engine node can hold millions of backends. This sounds extraordinary. Let's break down the math and the architecture that makes it arithmetic instead of marketing.

Each awake backend is a set of Tokio async tasks. Rust async functions compile to state machines — zero-allocation Futures optimized at compile time — so the per-task footprint is kilobytes: just enough to track where the task is in its query loop. And a suspended backend is even cheaper: not a task at all, but a timeline record plus cold bytes on object storage.

On the same hardware where legacy Postgres handles ~1,000 connections (each a 10-30MB OS process), Trubase DB multiplexes millions of backends. Of course, not all millions execute queries simultaneously. Most are waiting or asleep — and RAM only pays for the awake fraction. That ratio is the entire economics of the system: provision hardware for the active few percent, hold the total.

This is exactly what Tokio's work-stealing scheduler is designed for. Active tasks get CPU time. Waiting tasks consume only their few KB of state memory. Tokio distributes active tasks across all CPU cores automatically. When one core finishes its work, it steals tasks from another core's queue.

Compare this to legacy PostgreSQL: each connection is an OS process consuming 10–30MB of RAM — a 64GB server fits about 2,000. Connection poolers stretch that, but every pooled query still lands on a heavyweight OS process.

The difference is not 2x or 10x — it's orders of magnitude, a categorically different architecture. And it's only possible because the engine itself was rebuilt around tasks, instead of wrapping the C codebase with external proxies.