FAQ
FAQ
Before you migrate
What do I need before creating a migration?
- The database ports are reachable from where the engine connects (3306 for MySQL, 5432 for
PostgreSQL, etc.).
- HTTP (80), HTTPS (443), and SSH (22) are open if your host gates them.
- The database user has sufficient privileges — or is a superuser — on both source and target.
My database is only reachable over SSH — can I use it?
DBMigratePro connects with direct URLs like mysql://user:pass@host:3306/db or
postgresql://user:pass@host:5432/db. If your provider only exposes SSH, open a local tunnel and
point the URL at localhost:
ssh -N -L 3306:remote-mysql-host:3306 user@ssh-host
ssh -N -L 5432:remote-postgres-host:5432 user@ssh-host
Then use mysql://user:pass@localhost:3306/source_db and
postgresql://user:pass@localhost:5432/target_db.
What migrations are supported?
MySQL ↔ PostgreSQL (both directions), MySQL → MySQL, and PostgreSQL → PostgreSQL today. SQLite and
MongoDB conversions are on the roadmap. See Supported migrations.
Is there a size limit?
No — migrate databases of any size. Above 1000 GB we'd rather plan the run with you first,
so those route to a conversation instead of straight to checkout.
Security
Do you store my data?
For a migration, no: the engine streams data source → your target database and we don't keep a
copy. A backup is the opposite by definition — its whole job is to hold a copy — so each run is
encrypted before it leaves your database and stored either in our managed storage or in your own
bucket, whichever you picked. Nothing else is retained.
How are my connection URLs handled?
They're encrypted at rest and never logged. A one-time migration's URLs are purged after it
succeeds (a failed one keeps them for 24 hours so you can retry, then they're purged too). A
scheduled backup has to keep its URL — a 3 a.m. run with nobody there to paste anything needs
standing access — so it's held encrypted for as long as that backup exists, and deleted with it.
Pricing
How does pricing work?
Your first migration is free (source under 1 GB). After that you're charged per GB migrated
(rounded up to the whole GB) and only on success — a failed migration is never charged. Backups
are charged per GB of source per month, and restores are always free. Add a payment method to
keep going once your free run is used. Full details in Billing.
What happens if a migration fails?
It fails closed — no partial "success". You're not charged (the payment hold is released), the
timeline explains what happened, and you can retry once the cause is resolved.
How it works
Can I migrate between different clouds?
Yes. Source and target can be on any host or cloud — no lock-in. You provide both connection URLs.
Is downtime required?
A migration copies the source as it stands at one moment. For a clean cutover, stop writes to the
source (or migrate a read-only copy of it) so nothing changes mid-run.
How is a conversion different from a transfer?
A transfer is same-engine (MySQL→MySQL, PostgreSQL→PostgreSQL). A conversion is cross-engine
(MySQL↔PostgreSQL) with full type mapping and foreign-key handling — priced higher because there's
no simple DIY equivalent.
Do you support backups?
Yes. Point a schedule at a database and each run is encrypted, stored off your provider (our managed
storage or your own bucket), and restorable to any database on any host — which is the point:
if your provider locks you out, the backup isn't locked in with it. Restores are always free and
never metered. See Billing for the rates.
Can I restore to a different provider than the one I backed up from?
Yes — that's the design. A restore takes a target connection URL like a migration does, so the
backup you took on one cloud can land on another, or on your own server.
How do AI agents use this?
Agents drive the REST API with a bearer token. See
AI agents.
Still stuck?
Contact us and we'll help.