# DBMigratePro > Move a database anywhere. Paste a source connection URL and a target connection URL, > and DBMigratePro streams the data straight from one to the other. Same-engine > transfers — PostgreSQL to PostgreSQL, MySQL to MySQL, between any two providers, > clouds, or regions — are fully supported and are the cheaper of the two rates. > Cross-engine conversion, MySQL to PostgreSQL and PostgreSQL to MySQL, is supported > too. Either way foreign keys are preserved and row counts are verified before a run > reports success. It also takes scheduled, encrypted backups into object storage you > control, restores them to any database on any host, and can keep a target database > continuously in sync with a source until you promote it for a cutover. DBMigratePro is a hosted service operated by browser, REST API, or an AI agent over MCP. Nothing is installed on your database server: you supply connection URLs and the data is streamed directly from source to target, with no copy staged or retained in between. There is no size limit, and a migration that fails is never charged. Calling the API or MCP as an agent? Read https://dbmigratepro.com/auth.md first — how to obtain a token without a human copy-pasting one (a device-code flow), which abilities exist, the rate limits, and the rule for handling the user's database URLs. ## Problems this solves - Moving a PostgreSQL database to a different PostgreSQL host — a new provider, a new cloud, a new region, or your own server. Nothing is translated and no conversion layer is involved; it is a same-engine copy. The same applies to MySQL to MySQL. - Converting a MySQL database to PostgreSQL, or a PostgreSQL database to MySQL, with type mapping and foreign keys handled rather than hand-written. - Getting off a provider that is being shut down, repriced, or that has locked you out — anything that gives you a connection URL is a valid source and a valid target. - Getting scheduled, encrypted backups of a database that live somewhere your database provider does not control. - Restoring a backup onto a different provider than the one it was taken from, including when the original provider has locked you out. Restores are always free and never metered. - Moving providers with almost no downtime: keep a target continuously in sync with the source, then promote it during a short window instead of a long maintenance outage. The same mechanism doubles as a warm standby you control on a different provider. - Driving all of the above from a script or an AI agent instead of a dashboard. ## What it does - **Migration (same engine)** — copy a database to another database of the same engine: PostgreSQL to PostgreSQL, or MySQL to MySQL. This is a first-class use case, not a side effect of the converter, and it is the cheaper per-GB rate of the two. - **Conversion (cross engine)** — copy across engines (MySQL to PostgreSQL, PostgreSQL to MySQL), mapping column types and rebuilding constraints on the target. Costs more per GB than a same-engine transfer, so there is no reason to route a same-engine job through it. - **Continuous migration** — keep a target database on another server in sync with a source, same engine on both ends, on a repeating cadence: each pass ships new and updated rows and periodically reconciles deleted keys. The target runs minutes behind, not milliseconds, and syncing reads the source the way any client would — it never touches the source's replication configuration. Promoting the target stops the sync and hands it over as the live database; that is the cutover. - **Backups** — a schedule pointed at a database. Each run is encrypted before it leaves the database and stored either in DBMigratePro-managed object storage or in your own S3-compatible bucket, which you keep the keys to. Any completed backup can also be downloaded as gzipped plain SQL, loadable anywhere without special tooling. - **Restore** — take any completed backup run and write it into a target connection URL. The target can be a different engine host, a different provider, or your own server. Integrity is checked rather than assumed: foreign keys are preserved and validated, source and target row counts are compared at the end of a run, and a mismatch fails the run rather than reporting a partial success. ## Supported databases and directions MySQL (and MariaDB-compatible servers) and PostgreSQL. All four directions are supported: - PostgreSQL to PostgreSQL (same engine) - MySQL to MySQL (same engine) - MySQL to PostgreSQL (cross engine) - PostgreSQL to MySQL (cross engine) SQLite and MongoDB are not supported. ## Data handling and security Full statement, including what we do NOT have: https://dbmigratepro.com/security (plain Markdown: https://dbmigratepro.com/security.md). - **A migration is direct.** The engine opens your source and your target and streams rows between them. Nothing is staged on disk, no intermediate database is used, and no copy of your rows is retained. There is nothing in the middle but the process holding both connections open. - **One-time migration connection URLs are purged automatically** — about 1 hour after a successful run, about 24 hours after a failed one — by a job that runs every minute. - **Database connection URLs ARE stored for backup schedules.** This is stated plainly rather than glossed: an unattended overnight backup needs standing access with nobody there to paste a password. They are encrypted at rest, hidden from API responses, kept out of logs, and deleted when the backup is deleted. - **Backups are compressed and encrypted before they leave the machine that made them,** with an encryption key minted per run and stored only in wrapped form under a separate key that can be rotated on its own. - **Bring your own S3-compatible bucket and the data never enters an account we control.** It is written straight into your cloud account, is never mirrored or failed over into our storage, and is never deleted by us if your plan lapses. This is the configuration to use if the requirement is that the vendor must not hold the data. - **Storage keys never reach the engine.** It receives a presigned URL scoped to one object, one HTTP verb, and a short expiry, so a compromised worker yields nothing reusable. - **Restores are always free and never metered.** - **Sub-processors are enumerated by name** in the Privacy Policy (https://dbmigratepro.com/privacy), along with retention behaviour, the controller/processor split, and account deletion. - **We hold no SOC 2 report, and no ISO 27001, PCI DSS, or HIPAA coverage.** There is no penetration test report to share, managed object storage is not pinned to a region, and there is no object versioning on managed storage. Those gaps are published rather than omitted, and the Terms disclaim compliance fitness explicitly. ## Documentation - [Getting started](https://dbmigratepro.com/docs/getting-started): Run your first database migration — paste a source and target connection URL, and we stream the data across with foreign keys preserved and row counts verified. - [Authentication](https://dbmigratepro.com/docs/authentication): Authenticate the DBMigratePro REST API and MCP access with a personal API token — create one in Settings, then send it as a bearer token on every request. - [Migrations API](https://dbmigratepro.com/docs/migrations-api): Create and track database migrations over REST — the full pre-flight, create and poll flow, with copy-paste examples. No dashboard required. - [AI agents](https://dbmigratepro.com/docs/ai-agents): Operate DBMigratePro from an AI agent over MCP or the REST API, authenticated with a personal API token scoped to that token's user. - [Connect an AI assistant](https://dbmigratepro.com/docs/mcp-setup): Add the DBMigratePro MCP server to Claude Code, Claude Desktop, Cursor, VS Code, or Zed — real configuration for each client, the one-minute token step, and the guardrails an integrator needs to know about. - [Supported migrations & integrity](https://dbmigratepro.com/docs/supported-migrations): Which database migrations are supported — MySQL to PostgreSQL, PostgreSQL to MySQL, and same-engine transfers — and how row counts and foreign keys are verified. - [Continuous migration](https://dbmigratepro.com/docs/continuous-migration): Keep a target database continuously in sync with a source on another server, then promote it when you are ready to cut over — using nothing but two connection URLs. - [Billing](https://dbmigratepro.com/docs/billing): How billing works — migrations are charged per GB of data moved and only after a successful run. A failed migration costs nothing, and restores are never metered. - [FAQ](https://dbmigratepro.com/docs/faq): Common questions — what you need before migrating, connecting over an SSH tunnel, required database privileges, size limits, and how results are verified. - [Move Heroku Postgres to Neon, RDS or your own server](https://dbmigratepro.com/docs/move-off-heroku): Getting a Heroku Postgres database onto another host — the credential rotation that breaks half of these moves, which Neon endpoint to target, and what happens to Heroku's extensions. - [Move a Supabase database to Neon, RDS or your own server](https://dbmigratepro.com/docs/move-off-supabase): Getting a Supabase Postgres database onto another host — which schemas actually travel, why Supabase Auth does not come with you, and which of the two connection strings to migrate through. - [Convert MySQL to PostgreSQL without losing foreign keys](https://dbmigratepro.com/docs/mysql-to-postgres): What changes when a MySQL database becomes a PostgreSQL one — the exact type mapping, what happens to ENUM and zero dates, and how foreign keys and auto-increment survive the trip. - [Restore a backup to a different provider](https://dbmigratepro.com/docs/restore-to-another-provider): Getting a database back when the provider it lived on is gone, locked, or unreachable — what a restore needs, why the target must be empty, and how to do it without an account you no longer have access to. - [Back up a database from the command line](https://dbmigratepro.com/docs/cli): One command, no account — dump, gzip and AES-256-GCM a MySQL or PostgreSQL database to a local file, and load it again with tools you already have. - [Connect the CLI to your account](https://dbmigratepro.com/docs/cli-connect): Link the command line to a DBMigratePro account with one command — a browser login, no token to copy and paste, and a device-code fallback for servers with no browser. - [IP Allowlist](https://dbmigratepro.com/docs/ip-allowlist): The static IP ranges DBMigratePro connects from, so you can allow us in your database firewall instead of opening it to the internet. Every documentation page is also available as plain Markdown by appending `.md` to its URL — for example https://dbmigratepro.com/docs/getting-started.md. The complete documentation as a single plain-text file is at https://dbmigratepro.com/llms-full.txt. ## Guides - [Neon: how to migrate your database into Neon](https://dbmigratepro.com/blog/migrate-to-neon): Move a database to Neon in four steps with DBMigratePro — copy the direct connection string (not the pooled one), run pre-flight, migrate, and let verification check row counts and foreign keys against the source. - [How to set up a continuous migration and promote it with DBMigratePro](https://dbmigratepro.com/blog/setup-continuous-migration): Keep a target database continuously in sync with your source using nothing but two connection URLs, then promote it when you're ready — a near-zero-downtime cutover, or a warm standby you control. - [How to back up a DigitalOcean Managed Database (two ports, one firewall)](https://dbmigratepro.com/blog/backup-digitalocean-managed-database): DigitalOcean gives you two ports for the same database and only one of them is right for a backup, then blocks the connection anyway until you add a Trusted Source. Here is the order to do it in, and where the CA certificate fits. - [How to back up a Railway database (the internal hostname will not work)](https://dbmigratepro.com/blog/backup-railway-database): Railway hands you a connection string that resolves only inside Railway, so the first thing every external backup attempt does is fail to resolve a hostname. Here is which variable to use instead, and why Railway is a platform worth having a portable copy from. - [How to back up Render Postgres (internal vs external, and the expiry nobody reads)](https://dbmigratepro.com/blog/backup-render-postgres): Render gives you two connection strings and the one in front of you is usually the wrong one for a backup. Free instances also expire on a fixed date and are deleted — here is how to get a copy out, and the permission that makes a schedule keep working. - [How to convert PostgreSQL to MySQL with DBMigratePro](https://dbmigratepro.com/blog/convert-postgresql-to-mysql): Convert a PostgreSQL database to MySQL in four steps with DBMigratePro — paste two connection URLs, run pre-flight, migrate, and let verification check row counts and foreign keys against the source. - [How to convert MySQL to PostgreSQL with DBMigratePro](https://dbmigratepro.com/blog/convert-mysql-to-postgresql): Convert a MySQL database to PostgreSQL in four steps with DBMigratePro — paste two connection URLs, run pre-flight, migrate, and let verification check row counts and foreign keys against the source. - [Supabase: how to migrate your database into Supabase](https://dbmigratepro.com/blog/migrate-to-supabase): Move a database to Supabase in five steps with DBMigratePro — use the direct connection string, migrate with verification against the source, then enable row-level security on every imported table before the project takes traffic. - [How to back up a Neon database (and why branches are not backups)](https://dbmigratepro.com/blog/backup-neon-database): Neon's history and branching are excellent and they are not a backup, because both live inside Neon. Here is how to take a copy you hold — including the endpoint to schedule it against, and why the first attempt at 3 a.m. can fail when the same URL worked all day. - [How to back up a Supabase database (without dragging the whole platform along)](https://dbmigratepro.com/blog/backup-supabase-database): A Supabase project is a Postgres database plus several schemas Supabase owns. Dumping all of it produces something that will not restore cleanly anywhere else — here is which part is actually yours, which connection string to schedule against, and what a restore does not bring back. - [How to back up a PlanetScale database (Vitess changes the rules)](https://dbmigratepro.com/blog/backup-planetscale-database): PlanetScale is MySQL through Vitess, and Vitess refuses several things a normal mysqldump does by default — LOCK TABLES among them. Here is what to change, why the foreign keys in your dump may not mean what you think, and how to get a copy that restores onto ordinary MySQL. - [How to back up an AWS RDS database to storage outside AWS](https://dbmigratepro.com/blog/backup-aws-rds-database): RDS automated snapshots are excellent and they cannot leave AWS as a database — they restore to RDS, in your account, and nowhere else. Here is how to take a portable copy, and the two RDS-specific things that stop it working the first time. - [How to back up Heroku Postgres (the credentials rotate, and that breaks schedules)](https://dbmigratepro.com/blog/backup-heroku-postgres): Heroku can change your database credentials without asking, which is fine for a dyno reading DATABASE_URL at boot and fatal for anything that stored the URL. Here is why scheduled backups on Heroku fail weeks after you set them up, and what to point them at instead. - [How to set up automated database backups with DBMigratePro](https://dbmigratepro.com/blog/setup-automated-backups): Set up automated, encrypted database backups in four steps with DBMigratePro — paste a connection URL, pick a schedule and where the copies go, then rehearse one restore so the schedule is one you trust. - [Render: how to migrate your database into Render](https://dbmigratepro.com/blog/migrate-to-render): Move a database into Render Postgres in four steps with DBMigratePro — copy the External Database URL (not the internal one), run pre-flight, migrate, and let verification check row counts and foreign keys against the source. - [Railway: how to migrate your database into Railway](https://dbmigratepro.com/blog/migrate-to-railway): Move a database into Railway in four steps with DBMigratePro — copy DATABASE_PUBLIC_URL (the internal hostname won't resolve from outside), run pre-flight, migrate, and let verification check row counts and foreign keys against the source. - [PlanetScale: how to migrate your database into PlanetScale](https://dbmigratepro.com/blog/migrate-to-planetscale): Move a database to PlanetScale in five steps with DBMigratePro — choose MySQL or Postgres, flip the foreign-key switch if it's MySQL, then migrate with row counts and foreign keys verified against the source. - [Laravel Cloud: how to migrate your database into Laravel Cloud](https://dbmigratepro.com/blog/migrate-to-laravel-cloud): Move a database to Laravel Cloud with DBMigratePro — as a continuous migration that keeps syncing while your app stays up until you promote, or as a one-time migration with row counts and foreign keys verified against the source. Every guide is also available as plain Markdown by appending `.md` to its URL. ## For agents and integrations - [REST API](https://dbmigratepro.com/docs/migrations-api): create, inspect, and retry migrations over HTTP with a bearer token. - [OpenAPI description](https://dbmigratepro.com/openapi.json): machine-readable description of the REST API, generated from the live route table. - [Connect an AI assistant](https://dbmigratepro.com/docs/mcp-setup): copy-pasteable MCP setup for Claude Code, Claude Desktop, Cursor, and VS Code. - [AI agents](https://dbmigratepro.com/docs/ai-agents): what the MCP tools do and the rules an agent must follow. - [Authentication](https://dbmigratepro.com/docs/authentication): create a personal API token in Settings and send it as `Authorization: Bearer `. Both the REST API and the MCP servers authenticate with the same personal API token and are scoped to that token's account. An agent can never complete a payment on the user's behalf: when a run needs one it receives a checkout link to hand back to the user. Destructive calls ask for explicit confirmation before they act. ## Pricing Rates are published at https://dbmigratepro.com/pricing and are resolved live from Stripe, so they are deliberately not repeated here. The shape of it: migrations are charged per GB of data moved and only after a run succeeds, cross-engine conversions cost more per GB than same-engine transfers, backups and continuous migration are each charged per GB of source per month, and restores are always free and never metered. ## Limits worth knowing - MySQL and PostgreSQL only. - **One source to one target, whole database.** There is no way to merge several source databases into a single target, and no way to exclude specific tables or filter rows. If the job is "consolidate N databases into one, minus a few tables", this is not the tool. - Backups are scheduled logical dumps. Daily is the most frequent schedule available; there is no log-replay or transaction-level recovery. - 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 — or use continuous migration and promote. - A continuous migration target is minutes behind its source, same engine only, and is not a read replica: passes are not transactionally consistent snapshots, so it is for cutover and standby, not for serving read-your-writes traffic. - The database must be reachable from the internet on its own port. If your provider only exposes SSH, open a local tunnel and point the URL at localhost. - DBMigratePro holds no compliance certifications and makes no durability guarantee. See the security page above for the specific list of what we do not have. ## Other pages - [Pricing — Pay Per GB, Restores Always Free](https://dbmigratepro.com/pricing): A plan buys seats and features; databases are billed per GB per month with no allowance to run out of. Migrations are charged per GB and only when one succeeds. Restores are always free. - [Security & Data Handling — What We Store, and What We Do Not](https://dbmigratepro.com/security): Exactly how DBMigratePro handles your databases: a migration streams source to target directly, which credentials are kept and for how long, and what we do not have. - [Contact & Support](https://dbmigratepro.com/contact): Questions about a database migration, MySQL to PostgreSQL conversion, or backups? Ask the DBMigratePro team, or request support for another engine. - [Terms of Service](https://dbmigratepro.com/terms): The terms governing your use of DBMigratePro for database migration, cross-engine conversion, backups, and restores. - [Privacy Policy](https://dbmigratepro.com/privacy): How DBMigratePro handles your data: what is stored, how database connection details are protected, and how long anything is kept.