Postgres restore
Restore an OwnStack Postgres database from one of three sources: a publicly-fetchable dump URL, a Heroku Postgres backup, or a backup taken via ownstack stack backup. Restores happen on the stack — the CLI hands the work off to a worker; you don't transfer the dump through your laptop.
The three paths
| Source | Command |
|---|---|
| Public dump URL | ownstack db restore --app=<app> --url=https://… |
| Heroku backup | ownstack db restore --heroku-app=NAME [--backup=NUM] |
| Stack backup | Dashboard → Data → Restore from backup, or ownstack db restore --backup=<backup-id> |
Watching progress
$ ownstack db restore --app=<app> --url='https://…'
Restore queued (id 87).
$ ownstack db restores
$ ownstack db restore:info 87 --follow
The :info --follow form streams the live log: download progress, postgres:import output, target service restart.
What happens on the stack
- Worker SSHes to the stack and downloads the dump to a temp location.
- If the dump is custom format, runs
pg_restoreagainst the linked Postgres service. If plain SQL, pipes throughpsql. - Restarts the linked service so connections see fresh data.
- Cleans up the temp file.
Restoration is destructive
There is no in-place merge. If the target database has rows you want to keep, take a dump first via ownstack db dump. The CLI does not warn you before overwriting — that's deliberate, the command is supposed to do exactly what you asked.
Cancel a running restore
$ ownstack db restore:cancel 87
Cancellation interrupts the running pg_restore; the target database may be in a partial state. Re-run the restore from the start to fix.
The Heroku-importer flow
For migrating from Heroku Postgres without manually exporting + re-uploading:
$ ownstack db backups --heroku-app=my-heroku-app # list available backups
$ ownstack db backups:capture --heroku-app=my-heroku-app # take one now
$ ownstack db restore --heroku-app=my-heroku-app --backup=NUM # restore latest by num
OwnStack handles the Heroku CLI auth + signed URL fetch internally. You need a Heroku API key configured in the dashboard once.
After a restore: watch for password drift
If the dump was taken with pg_dumpall (or any flow that includes role globals), the restored Postgres role will have the source cluster's password. Your app's DATABASE_URL still has the OwnStack-side password. The next deploy fails authentication.
This is the single most common post-restore foot-gun. The fix is a one-statement ALTER ROLE. Full instructions: Repair after import.
Read next
- Repair after import — fix
password authentication failed. - Dumps
- Stack backups