pg_restore recreates a PostgreSQL database or selected objects from a custom-format or directory-format backup file.
pg_restore re-creates schemas, data, indexes, and privileges from a custom or directory-format backup produced by pg_dump, letting you rebuild a database after data loss or migrate it to a new server.
pg_restore handles .backup
files created with pg_dump -Fc
(custom) and folder dumps made with pg_dump -Fd
. Use psql
for plain SQL files.
Specify the target database with -d
, enable parallelism with -j
, and turn off ownership checks with --no-owner
when needed. These options minimize downtime during a restore.
Yes. Use -t
multiple times to pick objects such as Customers
or Orders
. pg_restore ignores everything else, shortening restore time.
Combine --schema
, --schema-only
, and --prefix
/--use-set-session-authorization
to direct objects into a different namespace while retaining permissions.
Creating a fresh database avoids conflicts with existing objects and lets you drop and retry without harming production data.
Run pg_restore -l backup.dump
to inspect contents, then test with pg_restore -f /dev/null -C backup.dump
before touching data.
Restoring into a database that still has active connections or different encodings causes failures. Disconnect users and match encodings beforehand.
pg_restore acquires object-level locks as it recreates each object. Users can still read unaffected tables, but writes to objects being restored are blocked.
If you used a directory-format backup with multiple jobs, you can rerun pg_restore; completed objects are skipped, reducing work.
Yes for large multi-table dumps. Small backups or heavily indexed single tables may not benefit and could even slow down due to coordination overhead.