Why we're building Trubase

Every app, every agent, every workflow needs a backend — a place to store state, run queries, hold data. Today, getting one means provisioning a server, spinning up a database instance, configuring networking, setting up authentication. It takes minutes at best, hours at worst. And when you're done? Tearing it down is its own project.

We kept asking: why? Why is a backend — the most fundamental state engine of any application — so expensive to create and so hard to throw away?

The answer is architectural. Legacy PostgreSQL spawns one OS process per connection, each consuming 10–30MB of RAM, scheduled by the OS kernel, communicating through rigid shared memory segments. A server with 1,000 connections burns 30GB of RAM just for connection overhead. This is why connection poolers exist — band-aids for an engine that can't multiplex natively.

Even modern 'serverless' databases wrap this same C engine with external page services, control planes, and connection proxies — because from outside the engine, orchestration is all you can build. Branching takes seconds. Nobody has made the backend a true primitive, because nobody owned the engine.

That's what Trubase DB is. Postgres, rebuilt from scratch in pure Rust on Tokio, with the backend lifecycle — mint, branch, suspend, wake, dispose — built directly into the engine. A backend becomes a lightweight task over a branchable timeline. Minting one is a metadata write.

Copy-on-write storage over object storage means branching duplicates zero data — a backend holding 1TB branches as fast as one holding 1KB. When idle, the tasks drop and their memory is reclaimed. $0 compute. The state persists as cold bytes.

We're building Trubase because backends should be as cheap as function calls. And nothing today delivers that.