How to migrate a database (Postgres/MySQL) to your own VPS

Moving a database feels risky because it is the part of your app that remembers everything: users, orders, posts, settings, payments, and all the little facts you cannot recreate by hand.

Short version: to migrate a database to your own server, you copy the data from the old Postgres or MySQL database, restore it on the new server, point your app at the new database, and verify that reads and writes work before you fully switch over. The safe version is not just “copy the data”; it is backing up first, planning a short write freeze or sync window, checking extensions and users, and keeping the old database untouched until the new one proves itself.

What are you actually moving?

A database is not one file in a folder. It is more like a small library with books, shelves, librarians, keys, and rules about who may read or edit which book.

When you move Postgres or MySQL, you are usually moving four things:

• the tables, which hold the actual rows of data
• the schema, which is the shape of the data: columns, indexes, constraints, and relationships
• users and permissions, which decide who can connect and what they can do
• database-specific extras, such as Postgres extensions or MySQL character sets

This is why a migration can look successful at first and still fail later. The app may load the homepage, but a search page is slow because an index was missing. A login may fail because the database user has the wrong permission. Text may look broken because the old and new databases disagree about character encoding.

Before you move anything, take a real backup and make sure you know how you would restore it. A backup you have never tested is more like a wish than a safety net. If you want the broader habit, read how to back up your server — and actually be able to restore it.

Should you use dump and restore, or replication?

Most small projects should use dump and restore. That means you export a snapshot from the old database, import it into the new one, then switch the app over. Think of it like taking a photocopy of the library at closing time and setting it up in a new building.

Replication is different. It keeps the old and new databases in sync for a while, so the final switch can be shorter. Think of it like hiring movers who carry each new book to the new library as soon as it arrives.

For many personal apps, small SaaS products, WordPress sites, dashboards, and internal tools, dump and restore is enough. The important part is deciding what happens during the gap between “copy started” and “new database is live.”

How do you avoid downtime and data loss?

The dangerous moment is not the copy. It is the switch.

If your old app keeps accepting writes while you are exporting the database, users can create new accounts, submit orders, or update settings that are not included in the exported file. That is how data goes missing even though the migration itself looked clean.

You avoid that with a simple plan:

1. Pick a quiet time.
2. Put the app into maintenance mode, read-only mode, or otherwise stop writes.
3. Export from the old Postgres or MySQL database.
4. Import into the new database.
5. Point the app at the new database.
6. Test the app as if you were a real user.
7. Only then allow writes again.

For a small site, this may mean a few minutes of maintenance. For a busy app, you may need replication or a more careful cutover plan.

Also check server size before the move. Database imports can be hungry: they use disk, memory, and CPU all at once. If the server is already tight on resources, the import may crawl or fail halfway through. For a plain-English sizing guide, see what size server do you need.

What breaks after the database moves?

The most common failures are boring, which is good news. Boring problems are easier to find.

The app may still point at the old database address. This is the classic “we moved the furniture, but the mail still goes to the old house” problem. Your application usually has a database connection string that includes the host, database name, username, password, and port. If one piece is wrong, the app may show errors like connection refused, password authentication failed, Unknown database, or ECONNREFUSED.

Versions can also bite you. A dump from a newer Postgres version may not restore cleanly into an older Postgres version. MySQL and MariaDB can be close cousins, but not always identical twins. Extensions, collations, SQL modes, and stored procedures can behave differently.

Performance can change too. The new server may have slower disk, less memory, or missing indexes. If the site becomes sluggish after the move, do not assume the migration “corrupted” something. It may simply be that the new database is working harder than the server can comfortably handle. This is the same family of problem covered in why is my server slow.

Keep the old database around, untouched, until you have watched the new one under real traffic. Do not delete your bridge while you are still checking whether the new road is open.

FAQ

Can I migrate Postgres and MySQL the same way? The broad pattern is the same: export, import, update the app, test. The tools and edge cases differ, especially around extensions, users, character sets, and versions.

Do I need to stop my app during the migration? If users can write data, usually yes, at least briefly. Otherwise you risk copying yesterday’s version of the truth while users keep changing today’s.

Can I just copy the database files from one server to another? Usually no. Raw database files depend on the database engine, version, and storage state. A proper dump or replication path is safer for most people.

How do I know the migration worked? Check row counts, log in as a real user, create test data, run the important app flows, and watch the app logs for database errors.

The shortcut

Server Manager helps by making the database move easier to see as a whole, not as a pile of half-remembered steps. The outcome you want is simple: the app points to the right Postgres or MySQL database, the old data is present, and the setup still makes sense when you look at it months later.

That matters because the common failures are not dramatic. They are a wrong database address, a forgotten password change, one project accidentally talking to another project’s database, or a setup that nobody can read after the person who built it has moved on. The real benefit is that the migration leaves behind a legible server, not just a working one.

You still need to decide when to switch and what to test. But you are less likely to lose track of which app uses which database, which environment is live, and what has to stay in place until the move is safely finished.

When the migration is done well, your database stops being the scary part of owning your server. You know where the data lives, how the app reaches it, and what to check if something feels wrong.