Zudoku
Use Cases

Serverless Databases

Run whichever database you already use, and start, clone and restore it in milliseconds.

Test migrations on a clone of production

Branch a running database (memory and volume state included) and run the risky migration against the copy.

few ms downtime on the original
Restore from a known good snapshot

Checkpoints keep a history of full instance state, so rolling back is a restore rather than a rebuild.

restore in < 10 ms
Idle databases cost nothing

State is snapshotted when the database goes quiet and restored on the next query. Per-tenant databases stop being expensive.

zero idle cost
Web server instance

The only thing that can reach the database

private VM ↔ VM
no public address
Primary database

Whichever database engine you run: memory and volume state, live

checkpoints
09:00
known good
12:00
now
Restore to known good
full state back in < 10 ms
branch
few ms downtime
Branch: migration test

A full clone, memory included; run the risky change here

One primary reachable only by your web server, branched in milliseconds when you need a copy to test against, and a checkpoint history to restore from when something goes wrong.

Watch the recording to see a running Postgres branched in 40 ms, written to without touching the original, and either copy woken in about 16 ms.


Under the hood

The platform features this use case is built on.

Clones a running database instance, including memory and volume state, with at most a few milliseconds of downtime on the original.

Capture the full state of an instance and keep a history, so you can restore from a known good snapshot.

Snapshots memory and volume state when the database is idle and restores it in milliseconds on the next request. Pay only for what you use.

The database can be hidden from the public internet entirely, reachable only by your web server.

Run your first serverless database

Sign up to Unikraft Cloud and follow the guide to run your first serverless database

Last modified on