MariaDB 11.0 renamed its clients, so
mariadb-dump and mariadb are accepted in place of mysqldump and mysql.
The lookup takes the first match from /usr/bin/which, then /opt/homebrew/bin, /usr/local/bin, and Postgres.app’s latest version. That path decides which client version does the work.
DuckDB is the exception: its dump is a statement the engine already in front of TablePro runs, over the connection that is already open.
File > Backup Dump… is dimmed on an engine that is not in the table, and on a libSQL connection pointed at a Turso URL rather than a local file, which sqlite3 cannot reach. For those, use a SQL export from Import & Export.
Restore is disabled on a read-only Safe Mode connection. Backup is not, because it writes nothing to the database.
The Backup Dump sheet with its scope tree, format and destination
Backup dump
1
Open the sheet
Choose File > Backup Dump… on a connected session, or right-click one or more databases in the connection tree and choose Back Up…. The tree’s selection arrives ticked.
2
Tick what goes in
The database being browsed starts ticked and whole. Tick more databases to write more files. Open a database’s disclosure triangle to reach its tables, all of them ticked, and untick the ones to leave out.
3
Pick the format and the folder
Only DuckDB offers a choice of format. Every file lands in the folder named under Save to, called
<database>-<yyyy-MM-dd-HHmmss> with the engine’s extension.4
Watch the byte counter
Cancel confirms, stops the run, and removes the partial file. Databases already written are kept. The result sheet lists every database with its file and size, and Show in Finder selects them.The bar shows a percentage on PostgreSQL and MySQL, which answer a database size query cheaply. The rest show an indeterminate bar with a running byte count.
What goes in
Ticking a whole database dumps everything in it: tables, views, routines, triggers and sequences, whatever the engine’s tool carries. Unticking even one table narrows the dump to the ticked ones, and every engine narrows differently.
The sheet repeats the relevant row under the tree as soon as a selection is narrowed. Leave every table ticked to get the whole database, which is what the sheet starts on.
Backing up several databases
Tick more than one database and the run writes one file per database into the chosen folder. Two databases whose names differ only by a character a file name cannot hold, such asa/b and a:b, get a numbered suffix rather than one overwriting the other.
Each database runs on its own. A failure stops that one and the run carries on, and the result sheet says which database failed and why alongside the ones that worked.
Restore dump
1
Pick the dump file
Choose File > Restore Dump… and select a file the matching backup tool wrote. The panel names the formats this connection’s engine accepts.
2
Pick the target database
Engines with more than one database ask which. SQLite and DuckDB reach exactly one, so they skip straight to the confirmation.
pg_restore runs with --no-owner --no-acl, so the connection user ends up owning the restored objects. mongorestore is scoped with --nsInclude to the database picked.3
Confirm
The dump is replayed into a database that already has contents. Objects it names are overwritten.
4
Wait it out
Restore shows no percentage. Cancel confirms and stops the run, and the target database is left as it stands: drop it and restore into a fresh one, or clean up the partial objects yourself.
--clean is passed, so restoring on top of a schema that already holds conflicting objects produces errors instead of replacing them. A DuckDB restore behaves the same way, and reports the first object whose name is already taken.
Restore covers the whole file. There is no table picker on the way back in.
What a dump carries
mysqldump runs with --single-transaction --routines --triggers --events, so a MySQL dump is consistent with itself and carries stored routines, triggers and scheduled events. pg_dump -Fc carries the whole database. sqlite3 .dump writes the schema and every row as SQL.
DuckDB writes one of two things. A .duckdb file carries tables, views, indexes, foreign keys and sequences, and only DuckDB reads it, which is also true of pg_dump’s archive and MongoDB’s. A Parquet folder holds schema.sql, load.sql and one Parquet file per table, which pandas, Spark and BigQuery read directly. Pick the file to restore into TablePro later, the folder to hand the data to something else.
SSH tunnels and SSL
Both flows reuse the connection’s active SSH tunnel, with no second port forward. SSL mode reaches PostgreSQL throughPGSSLMODE and MySQL through --ssl-mode, verify-ca and verify-full included. SQLite and DuckDB open a file, so neither applies.
Server-side export
Oracle, Snowflake and BigQuery do not have a client-side dump. They unload to somewhere the server can write: aDIRECTORY object, a stage, a Cloud Storage bucket. Choose File > Server-Side Export… for those.
Pick a table and name the destination. Oracle takes the name of a DIRECTORY object rather than a path, because the path belongs to the server. Snowflake takes a stage, with or without its @. BigQuery takes a gs:// prefix and shards its output under it.
The statement runs on your own connection, so it carries your privileges and the server’s own error comes back when the destination is not writable.
Snowflake and BigQuery block until the unload finishes, so the file exists by the time the sheet says so. Stop asks the server to cancel one and stops waiting either way.
Oracle is different. The Data Pump block starts a job and detaches, so the statement returns before anything is written and the sheet says the job was started rather than finished. Watch DBA_DATAPUMP_JOBS for its progress, and stop it there.
Nothing lands on your Mac. The result is on the server or in the bucket, and the sheet says where it went.
Passwords
Your password never reaches the tool’s argument list, which every process on the machine can read throughps. PostgreSQL gets PGPASSWORD and MySQL gets MYSQL_PWD, both in the environment. MongoDB’s tools read neither, so TablePro writes a 0600 config file and deletes it when the process exits. DuckDB is asked for nothing: it is already connected.