How to migrate a PostgreSQL database to Voroa: import guide

To migrate a PostgreSQL database to Voroa, create an empty managed Postgres database, open its Import tab, paste your current database’s connection string, and select Check, then Start import. Voroa copies your schemas, tables, data and indexes on its own servers. You do not need pg_dump files, and your connection string is used once and never stored.

The short version:

1. Create a new, empty Postgres (or Key-Value) database on Voroa.
2. Allow Voroa’s outbound IP addresses through your current database’s firewall.
3. Open the new database, go to Import, and paste your source connection string.
4. Select Check and read the result: size, version, access and encryption.
5. Select Continue, then Start import, and wait for Import complete.
6. Point your app’s DATABASE_URL at the new Voroa database and redeploy.

You can import from any PostgreSQL database that accepts connections over the internet, whether it runs on another cloud host, a managed database service or your own server.

Before you start

• Create the destination first. Add a new Postgres or Key-Value (Redis) database on Voroa (see How to add a managed Redis or Postgres). The import copies into this database, so it must be empty — a fresh database is ideal.
• Your source must be reachable over the public internet. Voroa connects to your existing database from our platform, so it needs a public host and port and credentials that allow an external connection. Databases that only accept connections from a private network cannot be reached.
• Allow our address through your source’s firewall. Most managed database hosts only accept connections from addresses you have listed. Add every address on Outbound IP addresses to that list before you start. This is the single most common reason an import cannot reach a source.
• Your data must fit your plan. The amount of data you import must fit your plan’s database storage. On a free managed Postgres that is 1 GB. If your source is larger, move the database to a bigger size first.

Import your data

1. Open your new (empty) database and go to the Import tab.
2. Paste your source database’s connection string, for example postgres://user:password@your-host.example.com:5432/your_db.
3. Select Check. Voroa connects to your database and reports what it found before anything starts: its size against your plan’s storage, its PostgreSQL version against this database’s, whether the destination is empty, roughly how long the copy should take, and whether the connection will be encrypted. Nothing is copied and nothing is used up by a check.
4. Select Continue — available once the checks pass — to review what is about to happen.
5. Select Start import.

The import runs on our side and can take a few minutes depending on how much data you have. You can leave the page — the status updates on its own, shows the time elapsed while it runs, and says Import complete when it finishes.

Stopping an import

While an import is running you can select Cancel import. Your database is left exactly as it was before you started, so you can correct whatever you need to and try again. Stopping an import is not a failure and does not count against you.

What the check tells you

The check answers the questions that used to surface only after a long copy had already failed:

• Size. Your source’s size against the storage your plan allows.
• Version. PostgreSQL restores into the same version or a newer one, never an older one. If your source is newer than this database, the check says so immediately rather than after the whole copy.
• Destination. Whether it is running and empty. If it is not, the check tells you how many tables are already there. Whatever one of your own failed imports left behind does not count as “not empty” - the retry replaces it (see below).
• How long. A range, not a single number - we can measure your database’s size on disk, but a copy moves a different amount of data, and your own connection speed is the usual limit.
• Encryption. Whether the copy will be encrypted. Some database hosts do not offer a secure connection at all; when that is the case we tell you plainly before you start, rather than quietly copying your data across the internet in plain text.
• Managed platforms. If your source is a platform that keeps its own machinery inside your database, the check names what will not be copied.

A check is advice, not a decision - you can start the import either way, and every check runs again for real when it begins.

Good to know

• Your credentials are never stored. The connection string you paste is used once to copy your data and is then discarded. It is never saved and never logged.
• Your existing data is safe. The import only reads from your source database; it never changes or deletes anything there.
• The destination is usually empty - but it does not have to be. By default an import copies into an empty database and stops if it finds data. If you already have data in your Voroa database and want the imported copy to take its place, choose Replace everything in it on the Import tab. See Replacing the data that is already there below.
• A failed import never blocks a retry. If an attempt failed or was interrupted part-way, whatever it left behind is replaced when you run the import again - you do not need to empty the database yourself. Until that retry completes, do not put your own data into that database: the retry replaces what the failed attempt left, and it cannot tell your later additions apart from it.
• One import at a time. You can run one import per account at a time; start another once the first finishes.
• Recent imports are listed. The Import tab shows your last few imports and what happened to each, so closing the page does not lose the answer.
• PostgreSQL and Redis. Importing into a managed PostgreSQL or Key-Value (Redis) database is supported. For PostgreSQL use a postgres:// source; for Redis use a redis:// (or rediss://) source.

Three more things that stop an import

• The destination must be running. If you stopped it, start it from the dashboard first — an import into a stopped database is refused rather than queued.
• You cannot import into a read replica. A replica is a copy of its primary and cannot be written to. Import into the primary instead.
• Your source must not be newer than your destination. PostgreSQL can restore a dump into the same version or a newer one, never an older one. If your source runs PostgreSQL 17 and your Voroa database runs 16, create a new database on 17 or 18 and import into that. New databases are created on 18 by default, which can read every version we support.

If the import stops

Voroa tells you which of these happened, rather than one general message:

Replacing the data that is already there

Moving to Voroa is rarely one clean step. If you have already created a Voroa PostgreSQL database and put something in it — a schema, a test load, an earlier partial copy — you do not need a second database to bring your real data across.

On the Import tab, under What should happen to this database, choose Replace everything in it. Then:

1. Run the Check as usual. It is answered for a replace, so it will not tell you the database is not empty — it tells you how much data is about to be replaced instead.
2. On the confirmation screen, type the database’s name to confirm. This is deliberate: it is the only thing standing between a mistyped click and your data.
3. Select Replace and import.

What you should know before you do it:

• Your application cannot read this database while the replace runs. The copy holds an exclusive lock on your data from the moment it starts until it finishes, so queries from your app will wait rather than answer. Plan it like a short maintenance window.
• If the copy fails, nothing is deleted. The old data is removed and the new data written in a single step, so a failure — a dropped connection, a source that stops responding, running out of room — leaves your database exactly as it was. This is the reason a replace is safe to attempt.
• We take a backup first, and we wait for it. Before anything is replaced, Voroa takes a backup of what is there now and refuses to start until that backup has finished. It appears in the Backups tab like any other, and you can restore from it. Because backups are picked up on a schedule, expect the import to wait a few minutes before it begins.
• Replacing needs room for both copies at once. Until the copy finishes, the old data and the new data are both on disk. If there is not enough room, the import is refused before anything is touched.
• PostgreSQL only. A Key-Value (Redis) database cannot be replaced this way; create a new one and import into that.

What comes across

Your own schemas, tables, data and indexes.

If you are migrating from a platform that keeps its own internal machinery inside your database — Supabase, for example, with its auth, storage and vault schemas — those internal parts are not copied, because they belong to that platform and cannot run anywhere else. Your own data is. This only happens when we can see that your source really is such a platform; an ordinary PostgreSQL database with its own schema named auth keeps it.

Once the import completes, point your service’s DATABASE_URL at the new Voroa database and deploy — your app is now running fully on Voroa. See what managed PostgreSQL on Voroa includes once your data is here.

Frequently asked questions

Do I need pg_dump to migrate my database to Voroa?

No. Voroa connects to your source database and copies it on its own servers, so there is no dump file to create, download or upload. You only paste a connection string. If you prefer to use pg_dump and pg_restore yourself, you can still connect to your Voroa database and do that.

Will the import change my existing database?

No. The import only reads from your source database. It never writes to it, changes it or deletes anything there, so your current app keeps running on it until you switch.

How long does a database import take?

It depends on how much data you have and how fast your source can send it. The Check step shows an estimated range before you start, and the Import tab shows the time elapsed while the copy runs. Small databases usually finish in a few minutes. A replace also waits a few minutes for its safety backup before the copy begins.

Is my database password stored?

No. The connection string you paste is used once to make the copy and is then discarded. It is never saved and never logged.

Can I import a Redis database?

Yes. Create a Voroa Key-Value database and paste a redis:// or rediss:// connection string on its Import tab. Replacing existing data in place is available for PostgreSQL only.

How do I avoid losing writes during the switch?

Your app keeps writing to the old database while the copy runs. For a clean cut-over, stop everything that writes to the old database just before you import: put the app in maintenance mode on its current host (on Voroa, use maintenance mode) and stop its background workers and scheduled jobs. Then point DATABASE_URL at Voroa once the import completes.