CloneDB

Pull a small, referentially-consistent slice of your production database into dev — driven by one config file.

Why CloneDB

Referentially complete

Follows foreign keys so your subset actually loads and runs — no orphaned rows. Cycles, composite keys, and cross-schema references are handled.

Config that maintains itself

Generate the config from your live schema, then regenerate to pick up new tables and columns while preserving every edit and comment you made.

Refresh in place

Upsert a fresh slice into a live dev database — re-runnable and idempotent. Or emit a portable SQL dump to load anywhere.

One static binary

No pg_dump shell-out, no server, no JVM. Connects to RDS, Cloud SQL, and AlloyDB with pluggable auth (IAM, Secret Manager, env, script).

The idea

You point CloneDB at a production (replica) database and a small config: a few seed rows — “the latest 30 days of orders”, “these 100 customer ids”, or a full SQL query — and it walks the foreign key graph to pull exactly what’s needed to keep the slice valid. Relationships are introspected, not hand-written; the config holds only your filters and a little policy.

[tables."public.accounts"]
sql = "SELECT id FROM public.accounts WHERE plan_tier = 'enterprise' LIMIT 25"
follow_children = true   # pull everything under those accounts, transitively

Then:

clonedb run --target "$DEV_DATABASE_URL"