Install

How SkelaDB works

PostgreSQL 18 on top and a storage engine that keeps every change underneath, all running in your cluster.

Install

Branch like you branch code

In the default object storage mode, every branch is a full, writable database that shares storage with its parent.

  • Fork from now, a timestamp or an exact log position
  • A new branch adds no storage until it changes
  • Optional dedicated-disk projects make full copies instead

Compute that sleeps

A quiet branch stops its compute, and the built-in proxy wakes it on the next connection.

  • Idle timeout per branch, down to seconds
  • Choose to stop, use a warm pool or pause
  • Pooling for thousands of short-lived clients

Every second is recoverable

Changes go to a replicated log and then into storage that is never rewritten.

  • A commit is safe once two of three WAL nodes have it
  • Restore to any second in your retention window
  • Read replicas stream from the same log

Storage priced like a bucket

By default your data lives in S3, Google Cloud Storage or Azure Blob, with a fast local cache in front.

  • Grows without resizing disks
  • Dedicated disks per branch when you choose them
  • Experimental: archive cold partitions to Parquet

Made for agents

Agents create databases the way people open tabs, and SkelaDB makes that cheap and safe.

  • MCP server and CLI as downloadable binaries
  • Project-scoped keys with expiry
  • An audit trail of every operation
skela branch create --name agent-7f3a \
    --parent $MAIN --idempotency-key task-7f3a
{ "operation_id": "3f1c…", "state": "queued" }
skela database query $DB \
    --sql 'select count(*) from events'
{ "rows": [[ 48213 ]] }

A console your team will use

Branch, run SQL, manage access, restore and watch performance in one place.

checkout-api/main
Search tables, branches, docs⌘K
Connect

checkout-api Active

PostgreSQL 18.4 · AWS us-east-1 · 6 of 24 branches running

Pooledpostgresql://app:••••@checkout-api.db.acme.internal/app
Queries / s2,418+12% vs yesterday
Connections148/ 400pooled by the proxy
Compute2.0CUautoscale 0.25 to 4
Storage18.4GB7 days of history
Computemain · last 24 hours
CUscaled to zero
Asleep6 h 10 m
Peak3.5 CU
Wakes4
Databaseson main
New
  • app42 tables
    14.2 GB
  • analytics18 tables
    3.8 GB
  • auth9 tables
    412 MB
Extensions
pg_trgmpgcryptopostgis

Measured, not promised

Every number comes from our own test runs, with the conditions beside it.

0.5ms

Durable commit

Median, on disk on two of three WAL nodes. Network between nodes not included.

0.3ms

Warm indexed read

Through the proxy, p95.

24ms

Page from object storage

One ranged read, no cache, 20 ms of storage latency added.

130ms

Branch to first write

Median on a 1M-row test database, without TLS or scheduling.

9ms

Resume from pause

Median. About 600 ms from a warm pool, 1.1 to 1.4 s from zero.

7.9k/s

Logins per proxy core

Full TLS and password check.

2×

Queries per core vs PgBouncer

One core, both resetting sessions between clients. About 1.4× against PgBouncer defaults; close to even on two cores.

From September 2026 runs on Linux and macOS test machines and a local Kubernetes cluster with half-core computes, in the default object storage mode. These are not production cloud measurements. Aurora's resume time is from AWS documentation.

The five parts

Each part runs as ordinary Kubernetes workloads next to your applications.

Proxy

Speaks the Postgres protocol and handles TLS, pooling and wake-ups.

Compute

PostgreSQL 18 with four small storage patches, one per branch, stopped when idle.

WAL service

Three nodes. A commit is durable once two have it on disk.

Pageserver

Serves any page from any point in history, with a local cache.

Object storage

Holds every history layer and WAL archive, in your own bucket.

Run it in your cluster

Install takes one command once your cluster, bucket and license key are ready.

Install See pricing