Serverless databases

Serverless postgres. On hardware you own.

Deploy a postgres (or redis, mysql, mongo) that scales to zero when nobody's connected and snapshot-wakes on the next connection in about 170 ms, no cold boot or recovery, with its data safe on a durable volume. Zero RAM when idle, a real database when it's needed. Your own Neon, self-hosted, with no per-query meter and no data leaving your metal.

See it in action →All features
  • zero RAM when idle
  • ~170 ms wake
  • fsync-durable volume
  • any TCP engine
A serverless postgres on a durable volume: it scales to zero when idle, and the next psql connection wakes it with the row intact

serverless, but self-hosted

Pay RAM only when someone's connected

Scales to zero on TCP

Not just HTTP. A published port is fronted by an L4 forwarder that wakes the app on the first connection and sleeps it when idle. The mechanism never parses the protocol, so postgres, mysql, redis, and mongo all work.

wake-on-TCP

Wakes without a cold boot

Sleep snapshots the running database and stops the VM; the next connection restores that snapshot in about 170 ms. The postgres process is already running in the restored memory, so there's no boot and no WAL recovery, just the row you left.

snapshot wake

Durable on a volume

The data directory lives on an fsync-honest block device. A committed row survives sleep, a redeploy, a hard VM kill, and a daemon restart. Sleep frees the RAM; the volume keeps the bytes.

persistent volumes

Pooled clients still sleep

A connection pool holds sockets open between queries; crucible reaps an idle connection so the app can still reach zero and sleep. The pool reconnects on its next query, the way serverless-postgres proxies work.

--connection-idle-timeout

No cloud, no meter

One Go binary on a box you own. No account to create, no per-query billing, no agent traces or customer data leaving your infrastructure.

self-hosted

Survives a restart

A slept database survives a daemon restart or a host reboot: it wakes from its durable snapshot onto a fresh instance, volume re-attached and data intact. Sleeping is not the same as losing it.

durable sleep

Back it up while it runs

volume backup takes a consistent point-in-time copy of a live database with no downtime: the volume is frozen only for an O(1) reflink copy. Under 2,500 inserts/sec the backup finished in about 90 ms with zero failed transactions. Restore it into a new volume, or clone one for a preview environment.

no-downtime backup

Backups on your storage

Point --backup-dir at another disk or a mounted store to keep backups off-host and off-cloud. No backup service, no egress, no per-GB bill: the bytes stay on hardware you own.

--backup-dir

deploy it

One command to a serverless database

postgres

Serverless postgres

A durable volume plus scale-to-zero. It sleeps when idle and wakes on the next connection.

$ crucible app create db \
    --image postgres:16 -p 5432:5432 \
    --volume pgdata:/var/lib/postgresql/data \
    --min-scale 0 --idle-timeout 30s

redis

Serverless cache

The same pattern for a request/response redis: zero RAM between bursts of use.

$ crucible app create cache \
    --image redis:alpine -p 6379:6379 \
    --min-scale 0 --idle-timeout 30s

connect

Just connect

The first client connection wakes it in about 170 ms from a snapshot; the data is right where you left it.

$ psql -h your-host -p 5432 -U postgres
# woke on connect, row intact

the serverless database, self-hosted

Zero RAM when idle. A real postgres when it isn't.

The economics of serverless databases, on hardware you already own, for any engine that speaks TCP.

$ curl -fsSL https://github.com/gnana997/crucible/releases/latest/download/install.sh | sudo bash -s -- --with-deps --enable
Star on GitHubRead the docs