Skip to main content
One of the most common DBDock workflows: overnight, pull production data into staging so the team starts each day with realistic data.

The simple version

That’s it — copydb streams from source to target with no intermediate file. Confirm the prompt and DBDock takes care of the rest.

Scheduled overnight refresh

Create a cron job (or Kubernetes CronJob / GitHub Actions scheduled workflow):
refresh-staging.sh:

Scrubbing sensitive data

Real user data in staging is a privacy/compliance risk. If your production database has PII, health data, payment info, or any regulated data, you need to scrub it before developers touch it.
The scrub-before-share pattern:

Partial refresh (schema only)

Want to keep staging’s data but align its schema with production?
This copies DDL (tables, columns, indexes, constraints) but not rows. Useful for schema drift detection.

Stale data detection

Add a check that staging is recent:
If the max is more than 24 hours old, alert the team — the refresh job may be broken.

Development workflow

For individual developers who want to pull latest prod data into their local:

Serverless Postgres hosts

If your staging or production is on a serverless Postgres (Neon, Supabase pooler, PlanetScale Postgres), pass --driver:
See the copydb reference for details.

See also

dbdock copydb

Full command reference.

Retention strategies

Keep backup counts sane.