Trubase: The instant serverless backend.
Trubase DB is Postgres rebuilt from scratch in pure Rust on Tokio, with the backend lifecycle — mint, branch, suspend, wake, dispose — native to the engine. Built in public against PostgreSQL's own 200,000-test suite.
What is Trubase?
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 is a value: minted in milliseconds, asleep at zero, branchable like git. One per user, per agent, per test, per PR — millions per engine node.
Why me
Olamilekan — founder, backend engineer, building Trubase DB in public.
My edge is not a resume line — it's a method that makes the resume irrelevant. Rebuilding Postgres has an unusual property: the spec already exists in executable form. PostgreSQL ships 200,000 tests that define exactly what correct means. I build against that corpus relentlessly and publish the pass rate as a live scoreboard.
Before writing engine code I completed the design end to end: the storage model, the wake path, the fleet topology, the verification strategy (deterministic simulation from day one), and the full engineering documentation corpus that governs the build.
Judge the artifacts, not the resume: the design corpus, the scoreboard, and the shipping cadence are all public, and any of them can be checked today.
Every backend today is heavy infrastructure
Legacy PostgreSQL spawns one OS process per connection — each consuming 10–30MB of RAM. A server with 1,000 connections burns 30GB of RAM just for connection overhead.
Even modern "serverless" databases wrap this same C engine with external page services and control planes — orchestration is all you can build from outside the engine.
AI agents mint and dispose of state at machine speed — isolated backends by the million, not connections by the hundred. Multi-tenant SaaS needs a physical backend per tenant, not a row in a shared table. The demand curve is arriving faster than any process-per-connection architecture can serve it.
How we achieve millions of backends per server
Tokio Work-Stealing Runtime
Every backend is a Tokio async task weighing kilobytes. Zero OS processes. Zero fork(). One engine node multiplexes millions of backends.
Rust Async State Machines
Each backend's query loop compiles to a Rust Future — a zero-allocation state machine. No GC. No runtime overhead.
Timeline Storage over Object Storage
The WAL is the database. Branching = writing a timeline record. Zero bytes duplicated. 10,000 branches share the same layers.
True Scale-to-Zero
When idle, tasks drop and memory is reclaimed. No container. State persists as cold bytes on object storage. $0 compute when idle.
What's built
Honest status: the design phase is complete and the build is starting, in public.
The market
Three converging forces
AI agents demand millions of isolated backends
Every AI agent invocation needs an isolated backend. Millisecond minting inside the engine is the forcing function.
PostgreSQL won the database wars
Every ORM, tool, and framework speaks Postgres. 100% observable compatibility eliminates adoption friction.
Rust + Tokio reached production maturity
The toolchain exists. Object storage is cheap enough. An executable spec plus AI-assisted engineering collapses the rewrite timeline.
Why wrapping the C engine can't get here
You cannot build this by wrapping C PostgreSQL. The C codebase assumes fork() + exec(), shared memory segments, and synchronous block I/O.
What we need from YC
Let's build this.
Trubase makes backends as cheap as function calls — minted, branched, slept, and disposed by the engine itself. We're building it in public, one passing test at a time.