● FOR INVESTORS

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. Millions per engine node, zero when idle.

01 — MARKET

The market

$103BCloud Database Market2025 est. (Gartner)
$15B+Serverless segmentFastest growing category
#1PostgreSQLThe database developers standardized on
AgentsThe new customerSoftware that mints backends by the million
02 — PROBLEM

Every backend today is heavy infrastructure

Legacy PostgreSQL spawns one OS process per connection — each consuming 10–30MB of RAM. With 1,000 connections, that's 30GB of RAM just for connection overhead. This is why connection poolers exist.

Even modern "serverless" databases wrap this same C engine with external page services and control planes — because from outside the engine, orchestration is all you can build.

03 — THE ARCHITECTURAL BREAKTHROUGH

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() calls. One engine node multiplexes millions of backend tasks.

Rust Async State Machines

Each backend's query loop compiles to a Rust Future — a zero-allocation state machine. No garbage collector. No runtime overhead.

Timeline Storage over Object Storage

The write-ahead log is the database. Branching = writing a timeline record. Zero bytes duplicated. 10,000 branches share the same layers.

True Scale-to-Zero

When a backend goes idle, its tasks drop and their memory is reclaimed. No container to shut down. Revenue and cost ride the same curve.

04 — MOAT

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, OS-level process isolation, and synchronous block I/O to local disk.

→Platforms that added branching did it with external storage services — getting task-per-backend means rewriting the engine.
→Platforms that added a backend surface run it as always-on services — so the full backend can never sleep.
→Managed-instance providers automate the old architecture without changing it. No path from instance economics to task economics.
→The only way to millions of task-backends per node is to rebuild the engine itself. That is an enormous effort — which is precisely the moat.
05 — FOUNDER

The founder, and the method

Olamilekan — founder, backend engineer, building Trubase DB in public.

Solo-founder, full-commitment build with a method designed to be verifiable at every step. The spec already exists in executable form — PostgreSQL's own 200,000-test corpus — and the engine converges on it in public.

Before a line of engine code, the design phase was completed end to end: the architecture, the storage model, the wake path, and the verification strategy.

06 — ECONOMICS

The structural advantage

Traditional model
1 backend1 OS process = 10-30MB RAM
1,000 backends1,000 processes = 30GB RAM
1M backendsImpossible
Idle costFull price
Trubase model
1 backend1 Tokio task = a few KB
1,000 backendsA few MB total (CoW shared)
1M backends~2GB total
Idle cost$0

Architecture arithmetic from per-task footprints — not a measured benchmark. Measured numbers ship on the public scoreboard.

Let's talk.

We're raising our seed round. If you invest in infrastructure and believe backends should be as cheap as function calls — reach out.

olamilekan@trubase.devJoin Waitlist