SkelaDB

Serverless PostgreSQL in your own cloud

By Arpan Bhandari

Source: https://arpan.sh/projects/skeladb

A serverless PostgreSQL platform with database branching and idle compute suspension in your own cloud account, built in Rust.

I'm building SkelaDB, a serverless PostgreSQL platform that runs in the user's own cloud. Database branching and idle compute suspension let developers test changes against existing data without waiting for a full database copy or keeping another database instance running indefinitely.

My work covers the Rust storage services, PostgreSQL integration, connection proxy, control plane, and deployment tooling.


Separating the lifetime of compute and data

I chose to separate compute from storage so PostgreSQL instances can be stopped or replaced while their data remains available. Branches share stored history with their parent and only diverge as new writes arrive.

That makes branching cheaper than copying the full dataset, but puts more responsibility on the storage system. A branch must start from a consistent point, retain the history it needs, and recover acknowledged writes after compute is lost. Those requirements shaped the boundaries between log ingestion, branch publication, and startup.


Optimizing the operation a developer waits for

I measured branch creation through the point where it could read data and commit a write. Timing only the creation of branch metadata would have missed most of the wait.

The work included batching page reconstruction and loading independent storage layers concurrently. I moved advisory reports and obsolete-file cleanup out of the response path, while keeping the writes required for durability in place.

In a September 2026 local benchmark, SkelaDB completed branch operations with a median of 118 ms for 100K rows and 151 ms for 1M rows. All 120 SkelaDB branches passed the correctness checks, along with six storage-loss recovery checks.

The local Neon comparison measured 131 ms and 125 ms respectively. The smaller workload was faster on SkelaDB; the million-row workload still showed a gap. Both measurements excluded deployment scheduling and used SQL without TLS.

Those results kept the next optimization focused on the complete operation. A faster storage stage is only progress if the branch becomes usable sooner and still recovers its data.

The optimization article [https://arpan.sh/writing/skeladb-branch-optimization] goes through an earlier round of this work. SkelaDB's source is private, with container images and installation tooling available through the public repository [https://github.com/arpan404/skelaDB].