Not without inspection. The PostgreSQL documentation warns that restoring a dump causes the destination to execute arbitrary code of the source superusers' choice. If the source is not trusted, read the SQL first, or restore into a disposable instance with no network path to anything you care about.
What the warning says
The pg_dumpall reference carries a plain warning. Restoring a dump causes the destination to execute arbitrary code of the source superusers' choice. Partial dumps and partial restores do not limit that. If the source superusers are not trusted, the dumped SQL statements must be inspected before restoring.
A dump is a script. It can create objects, functions, triggers and extensions, and run whatever SQL its author put in it. Treating a dump as inert data, like a spreadsheet, is the mistake.
When this comes up
| Situation | Risk level to think about |
|---|---|
| Restoring your own nightly backup | Low, if the source was not compromised |
| A copy from a vendor or consultant | Review before restoring |
| A dump found in a ticket or shared drive | Treat as untrusted |
| A production copy someone modified for debugging | Review for added objects |
| A sample database from a tutorial | Restore into a throwaway instance |
The point is not paranoia about your own backups. It is that the trust boundary sits at the source of the script, not at the file format.
What a cluster dump adds
The same reference explains that pg_dumpall also dumps global objects common to all databases: database roles, tablespaces and privilege grants for configuration parameters. It notes that pg_dump does not save these objects. A full cluster restore can therefore bring roles and grants along with the data, which makes inspection more important.
For ownership, the docs say a script can be made restorable by any user with the option that gives that user ownership of all objects. That is the short flag O on the command line. Useful for a developer copy, but think about whether the resulting ownership matches your role design. See separating migration and runtime roles.
A safe restore routine
- Get the dump over a channel you trust, and compare a checksum with the sender if you can.
- Open the SQL and search for roles, functions, triggers, extensions and anything that calls out of the database.
- Restore into a disposable instance, such as a throwaway container with no published port and no credentials to other systems.
- Do not restore as a superuser unless the task needs it.
- After the restore, list the objects and compare them with what you expected.
- Delete the disposable instance when done.
If you are restoring a real production backup, also confirm the backup itself is good. See verifying a PostgreSQL backup.
Dev copies of production
Copies of production data in lower environments bring their own risk. See your staging environment has production data and do backups contain plaintext secrets.
Where this fits in software supply chain thinking
A dump from a third party is an input to your system, just like a package. You would review a dependency before installing it. Apply the same instinct to anything that runs code on your database.
Safeguard scans dependencies and builds an SBOM so you can see what code you are pulling in. A free scan is at gold.safeguard.sh/scan.
Quick check
Is a plain text dump safe to restore because I can read it?
Only if you actually read it. The docs say the statements must be inspected when the source is not trusted.
Does pg_dump include roles?
The docs say pg_dumpall dumps roles, tablespaces and configuration parameter grants, and that pg_dump does not save them.
What is the safest place to test a dump?
A disposable instance with no network path to other systems, deleted afterwards.
Sources
Last reviewed: 19 October 2026.
