Backends should be disposable

In 2013, Docker made compute disposable. You could spin up a container in seconds, use it, and throw it away. This changed everything — CI/CD, microservices, dev environments, testing. The entire industry reorganized around disposable compute.

But we never did the same for backends. Your database is still a precious, long-lived, carefully-managed resource. You provision it once, nurture it, back it up, and pray nothing goes wrong. Creating a new one takes minutes. Throwing one away feels dangerous.

Even 'serverless' databases today take seconds to branch and lean on heavy control-plane orchestration. Why? Because they wrap the legacy C engine from the outside. That engine assumes one OS process per connection, shared memory segments, and synchronous disk I/O. You can't make this architecture disposable without replacing the architecture itself.

That era is over. By rebuilding Postgres in pure Rust on Tokio with the backend lifecycle native to the engine, each backend becomes a lightweight async task instead of a 30MB OS process. Minting 10,000 backends is a rounding error on a single node. Disposing one means dropping a pointer. State persists on object storage.

Imagine if every AI agent invocation got its own physical Postgres backend — branched in milliseconds from a template, free to read and write anything, disposed when done. No shared state, no conflicts, no cleanup. Imagine if every user in a multi-tenant app had their own backend — real physical isolation, not a policy workaround.

This is what happens when you make backends disposable. The same revolution that containers brought to compute, applied to state. That's what we're building with Trubase DB.