Backup & restore — rdSQL Docs

Right-click a connection, database, or schema in the sidebar and choose Backup or Restore. A copy keeps tables, every row, primary keys, column defaults, auto-increment / serial / identity counters (moved past the copied ids) and PostgreSQL enum types — so the target keeps working for inserts, not just for reads.

Every backup-then-restore and backup-into-another-connection path is checked row for row by an automated end-to-end suite against real PostgreSQL, MySQL, MariaDB, SQLite, DuckDB, CockroachDB, YugabyteDB, TiDB and SQL Server servers.

Back up#

Pick the tables, and for each whether to copy its structure, its data, or both.

Choose the destination:

Destination	What it does
File	Writes a plain `.sql` script you can restore with rdSQL or your usual command-line tool.
DB connection	Copies straight into another connection of the same engine (PostgreSQL and Neon count as one). For PostgreSQL you pick the target schema — it is created if it doesn't exist yet; for the MySQL family you pick the target database.
S3 storage	Uploads the script to S3, R2 or MinIO, optionally gzip-compressed, with a metadata file next to it.

Choose how to treat tables that already exist on the target: insert only, truncate first, or drop and recreate.
Click Start Backup. If something fails, the run pauses — fix the cause and click Resume to continue from the same row.

What a copy keeps#

From PostgreSQL and Neon, a backup keeps every index, UNIQUE / CHECK / EXCLUDE constraint and foreign key, created after the rows are in, the way pg_dump orders them. A foreign key is copied when the table it references is copied too. Rows are written as COPY blocks (to a file) or sent with the COPY protocol (to a connection), which is several times faster than INSERT statements on a cloud database — restoring a ~470,000-row backup into Neon went from about 2 minutes to under 30 seconds.

On other engines, indexes other than the primary key, unique constraints and foreign keys are not copied yet. Views are never copied, and values travel exactly — JSON, binary data, very large integers, intervals, IP addresses and all.

Restore#

Right-click the connection to restore into and choose Restore.
Pick a .sql file from disk — or From Storage for a file in S3. The dialog tells you what kind of script it is (rdSQL backup, pg_dump script, mysqldump script, or plain SQL) and its size.
Check the options:
- Stop on first error (on by default) — pause at a failing statement; fix the cause and Resume from it.
- Ignore database name baked into the file (on by default) — run every statement in this connection's database, whatever the file names, skipping its USE statements. Not used for pg_dump scripts.
- Skip ownership and privileges (on by default) — leave out OWNER TO, GRANT and REVOKE, which name users from the server the dump came from.
Click Run Restore.

The file is read a few megabytes at a time, so its size doesn't matter, and statements run in the file's own order on one session — as psql or mysql would run them. Scripts made by pg_dump and mysqldump / mariadb-dump are supported natively: COPY ... FROM stdin data is loaded with COPY, psql meta-commands such as \restrict are skipped, and binary values that mysqldump writes as raw bytes keep their exact bytes.

When it finishes, the log ends with the number of statements run, rows copied, and anything skipped — and the full log is saved to a file next to the run.

Troubleshooting#

session_replication_role / permission denied — switching foreign-key checks off needs superuser, which managed PostgreSQL (Neon, RDS, Supabase) doesn't grant. The restore notes it and continues; tables are created parents-first so the data still loads.
"column … does not exist" on insert — the target already has a table with that name but different columns. Back up again with Drop & recreate, or restore into an empty database.
"role … does not exist" — leave Skip ownership and privileges on; the dump grants privileges to users that only exist on the source server.