True scale-to-zero: what it actually means

Every serverless database claims scale-to-zero. But what does that actually mean? For most, it means 'we charge you a reduced minimum fee when your database is idle.' That's not zero. That's scaled down.

True scale-to-zero means: when your backend has no active queries, it consumes zero compute resources and costs $0. Not a reduced minimum. Not a paused container that still occupies cluster capacity. Zero.

In Trubase DB, when a backend goes idle, its tasks complete and their memory returns to the runtime — available immediately for other backends. There is no container to shut down. No VM to drain. No process to kill.

All state persists on object storage. The layers, the archived WAL, the timeline metadata — everything durable is already durable before the suspend. Nothing is lost when the tasks drop.

When a connection arrives for that backend, the wake begins during the TLS handshake. Suspension is a spectrum: a dozing backend kept its cache and wakes in microseconds; a sleeping one wakes from local NVMe in sub-milliseconds; a hibernating one wakes with a single batched object-storage fetch, because its resident state was freeze-dried at suspend. No container to start, no VM to boot, no orchestration — spawn tasks, attach state.

This is architecturally impossible in C PostgreSQL. The C engine's process model requires OS-level process teardown (closing file descriptors, unmapping shared memory, signaling the postmaster) and startup (forking, initializing shared buffers, loading catalog caches). That takes hundreds of milliseconds at minimum. Wrapping it in containers makes it even slower.

True scale-to-zero is not a feature you bolt onto an existing engine. It's a property that emerges from the right architecture: task-per-backend compute, timelines on object storage, and engine nodes that hold nothing but caches.