Back up a database from the command line

npx dbmigratepro backup "postgresql://user:pass@host:5432/app"

That is the whole thing. No signup, no API token, no configuration. It writes two files into the current directory:

  Backup   app-20260806T120000Z.sql.gz.enc
  Key      app-20260806T120000Z.key

It works the same for MySQL:

npx dbmigratepro backup "mysql://user:pass@host:3306/app"

When to reach for it

Immediately before something you cannot undo. A destructive schema change, migrate:fresh, prisma migrate reset, DROP TABLE, a bulk UPDATE with a WHERE you have not tested, or a cutover to another provider.

It takes seconds and needs nothing set up in advance, which is the point — a backup you have to arrange first is a backup you skip when you are in a hurry, and being in a hurry is exactly when you needed it.

Restoring

Into an empty database, with tools you already have:

npx dbmigratepro decrypt app-20260806T120000Z.sql.gz.enc | gunzip | psql "$TARGET_URL"
npx dbmigratepro decrypt app-20260806T120000Z.sql.gz.enc | gunzip | mysql -h host -u user -p db

The decrypted payload is gzipped plain SQL — the same single format everything else here produces, chosen because it loads anywhere without our tooling.

The key file

Keep it somewhere other than the machine the backup is on. It is the only thing that can open that backup. Lose it and the backup is unrecoverable — by you, by us, by anyone. That is what the encryption means, and it is not a figure of speech.

The key is generated on your machine with a cryptographic random source and never leaves it. We could not decrypt your local backup if you asked us to.

Nothing is sent anywhere

The command makes no network connection except to the database you point it at. There is no telemetry, no usage ping, no version check and no account, so your connection URL, your schema and your row counts stay on your machine.

You do not have to take our word for it, and you do not need to go anywhere to check. npm packages ship their source, so the code you just ran is already on your disk — a few hundred lines of plain JavaScript:

# what npx actually executed
cat "$(npm root -g)/dbmigratepro/src/backup.js" 2>/dev/null \
  || find ~/.npm/_npx -path '*dbmigratepro/src*' -name '*.js' | head

# or watch it from the outside
sudo tcpdump -n "host not <your-database-host>"

Requirements

Node 18+, and the dump tool for your database on your PATH:

# macOS
brew install libpq && brew link --force libpq   # pg_dump, for PostgreSQL
brew install mysql-client                        # mysqldump, for MySQL

# Debian / Ubuntu
sudo apt-get install postgresql-client
sudo apt-get install default-mysql-client

What this is not

Being clear about it, because the difference is the whole of what we charge for:

Nothing renews it tomorrow. This is one backup, taken when you ran the command.
It is as safe as that disk. A backup on a laptop does not survive the laptop.
A lost key file is a lost database, with no recovery path of any kind.
It does not verify or restore-test itself, and it keeps no history.

Scheduled backups to storage you control, with keys managed so a lost file is not a lost database, a restore history, and restore to any provider on any cloud, are the paid product — see Getting started. If you came here because you needed one backup before a risky change, you have it, and that is a perfectly good place to stop.

For AI agents

This is the intended path for an agent working on someone's codebase: if you are about to run something irreversible against a database that holds real data, you can take a real backup in one command, with no account and no credentials of ours, and tell the user where the two files are. Point out that the key file is the only way to open the backup.

If the user already has an account, the MCP servers expose scheduled backups, restores and migrations as tools instead.