Open source · MIT · self-hosted

Move a PostgreSQL database.
Prove nothing was lost.

A dump-and-restore that refuses to start if the copy could lose data — then counts every row on both sides to show you it didn't.

View source
Source
postgresql://…@ep-cool-name.neon.tech/appdb
Destination
postgresql://…@your-server:5432/appdb
pre-flight›dump›create› restore›analyze›verify
What it handles for you

The six ways a manual pg_dump goes wrong

Every one of these has cost somebody a weekend. dbclone checks for all of them before it writes a single byte.

Proof, not hope

Three layers of verification

A clone is only reported as successful when all three match. Anything that differs is listed by name.

Honest limits

What it will not do

Copy server-level roles and passwords pg_dump works per database. Create application users yourself.
Downgrade across major versions 18 → 16 is impossible in PostgreSQL itself. Rejected up front, not halfway.
Move a 50 GB database quickly It works, but replication-based tooling is the right answer at that size.
Store your credentials Connection strings live in memory for one job, then they are gone.

New transfer

Pick both ends, then clone with verification — or just compare what is already there.

Source

Read only — never modified.

not tested

Destination

Connect to any database on that server.

not tested

Run

Pre-flight runs first. If anything could be lost, nothing starts.

Progress

Live log 0 lines

History

Only your own runs are listed. Connection strings are stored masked.