pg_dump Command Generator
pg_dump has more than sixty flags and several of them silently do nothing in the wrong combination — parallel jobs outside the directory format, compression on a plain dump, --clean with --data-only. Describe the backup you want and this generator writes the pg_dump command, the matching pg_restore or psql command to bring it back, and a warning whenever two options contradict each other. It runs entirely in your browser and never sees your database.
⚠ Parallel dump (-j) only works with the directory format. The -j 4 flag was left out of the pg_dump command; switch the format to "directory" to dump in parallel.
Do more than pg_dump command generator — meet Chat2DB
Chat2DB is an AI-powered SQL client for Windows, macOS and Linux. Write SQL in natural language, format and optimize queries automatically, and manage MySQL, PostgreSQL, Oracle and 20+ other databases in one workspace.
How to use
- Enter the connection details for the database you want to back up and choose an output format — custom is the right default for most backups.
- Choose whether to dump schema, data or both, then add any schema or table filters and set the parallel job count.
- Copy the pg_dump command, then keep the generated pg_restore command and verification SQL for the day you actually need the backup.
Frequently asked questions
Which pg_dump format should I use?
Use the custom format (-Fc) unless you have a specific reason not to. It is compressed by default, and because pg_restore can read its table of contents you can restore a single table, reorder the restore, or list the dump's contents without unpacking it. Use directory format (-Fd) when you want a parallel dump, since it is the only format pg_dump can write with multiple jobs. Use plain format only when you genuinely want a readable SQL file to replay with psql.
Does pg_dump lock the database or block writes?
No. pg_dump runs inside a repeatable-read transaction and takes only an ACCESS SHARE lock on each table, so ordinary reads, inserts, updates and deletes keep running. What it does block is anything that needs an ACCESS EXCLUSIVE lock, such as ALTER TABLE, DROP TABLE or TRUNCATE on a table being dumped — those will wait for the dump to finish. The dump is a consistent snapshot of the moment it started, so changes made during the run are not included.
Is pg_dump enough for production backups?
It depends on how much data you can afford to lose. A pg_dump is a logical snapshot of one point in time, so your worst-case data loss is everything written since the last dump — and restoring a large database from a dump means replaying every statement and rebuilding every index, which can take hours. For production, combine a physical base backup taken with pg_basebackup or pgBackRest with continuous WAL archiving so you can do point-in-time recovery, and keep logical dumps for moving data between versions or extracting single tables.
