We're building the instant serverless backend.

Founder. Backend engineer. Building Trubase DB in public.

Rebuilding Postgres is the kind of project that used to require a research lab. What makes it tractable now is that the spec already exists in executable form — PostgreSQL's own 200,000-test corpus — and the discipline is to build against it relentlessly, with the pass rate published as a public scoreboard from the first milestone.

That's the founding method: no claim ever exceeds the number, every subsystem is designed in writing before it's built, and the entire engineering documentation corpus is part of the product, not an afterthought.

If you want to follow the build, question the architecture, or challenge the numbers: olamilekan@trubase.dev.

We believe backends should be as cheap as function calls. That every agent, every user, every workflow should have its own complete, isolated Postgres backend — instantly, serverlessly, for near-zero cost.

Legacy PostgreSQL spawns one OS process per connection, each consuming 10–30MB of RAM. A server with 1,000 connections burns 30GB just for connection overhead. This is why connection poolers exist — band-aids for an engine that can't multiplex natively.

We took the harder, necessary path: rebuilding Postgres from scratch in pure Rust on Tokio, with the backend lifecycle — mint, branch, suspend, wake, dispose — native to the engine.

Tokio is a multi-threaded async runtime for Rust that uses a work-stealing scheduler. When a backend task is waiting on storage or network I/O, it yields the CPU — zero waste. When one CPU core finishes its work, it steals tasks from other cores' queues — perfect load distribution.

Each backend's query loop — read packet, parse SQL, plan, execute, write response — compiles to a Rust Future, a zero-allocation state machine. No garbage collector. No runtime overhead.

This is architecturally impossible in C PostgreSQL's fork()-based process model. You cannot bolt Tokio onto C Postgres. You must rewrite the engine.