Skip to content
DockHiveDockHiveDockHive Docs

Import from another provider

Move an existing PostgreSQL, MySQL or MariaDB database to DockHive in a few clicks. DockHive connects to your current database, copies everything into a DockHive database and checks that every table arrived complete. Importing is free: incoming data isn’t billed.

It works with any provider that lets you connect over the internet: Supabase, Neon, AWS RDS and Aurora, Google Cloud SQL, Azure, Heroku, Railway, Render, DigitalOcean, PlanetScale, or your own server.

Before you start

Section titled “Before you start”
  1. Get a connection string for your current database. A read-only user is enough: it only needs to read every table you want to copy.
  2. Allow DockHive’s address in your current provider’s firewall or IP allow list. When you click Check connection, the console shows the address to allow for the region you picked.
  3. Pick how to move.
    • One-time copy: copies everything once. Changes made to your old database after the copy starts aren’t included, so stop your app’s writes (or use a short maintenance window) before you import.
    • Copy and keep in sync: copies everything, then keeps applying new changes until you switch over, so you can move with almost no downtime. See Keep in sync, then switch over.

Import into a new database

Section titled “Import into a new database”
  1. On Databases, click Import a database.
  2. Paste your connection string (or fill in host, port, database, user and password) and pick the region for the new database.
  3. Click Check connection. DockHive connects to your database and shows its version, size, tables and schemas, plus anything that needs your attention.
  4. Review the suggested engine, version and storage size, then click Create database and import. DockHive creates the database, waits until it’s running and starts the copy.

You land on the new database’s Migration tab, where you can follow the copy.

Import into an existing database

Section titled “Import into an existing database”

Open the database, go to Migration → Import Data, paste the connection string, click Check connection, then Start import.

The database must be empty. If it already has tables, you can choose to replace everything in it (you type the database name to confirm): the database is emptied first, so it ends up with exactly your source’s tables and data.

Keep in sync, then switch over

Section titled “Keep in sync, then switch over”

Choose Copy and keep in sync in the import form to move a live database with almost no downtime. DockHive copies everything, then keeps your DockHive database up to date with every change made to your old one, for as long as you need (up to 14 days). When you’re ready, you switch over in a few seconds.

  1. Check the connection with Copy and keep in sync selected. The check shows a readiness list: every item must have a ✓. Each ✗ comes with the fix, often a single setting or SQL statement you can copy.
  2. Click Start sync. The Migration tab shows Connecting, Copying, then In sync, with a live badge: Up to date, N s behind or Catching up.
  3. Test your app against the new database if you like, but don’t write to it until you switch over: changes made there can break the sync.
  4. When you’re ready, click Switch over and follow the steps:
    1. Stop writes to your old database (maintenance mode, or scale your app’s workers to zero).
    2. Click Switch over. DockHive waits for the last changes, stops the sync and checks the row count of every table.
    3. Point your app at the new connection string shown in the dialog.

If the last changes haven’t arrived yet (for example because writes were still happening), you’ll see Not caught up yet: nothing is lost and the sync keeps running, so stop the writes and try again.

Stop sync cancels the sync and empties the DockHive database (you type its name to confirm). Nothing changes on your old database except that DockHive’s replication setup is removed.

What your old database needs

Section titled “What your old database needs”
PostgreSQL MySQL / MariaDB
How it syncs Logical replication Binary log replication
Setting wal_level = logical Binary log on, binlog_format = ROW
User The owner of the tables, with replication rights (a read-only user isn’t enough) REPLICATION SLAVE, REPLICATION CLIENT and RELOAD, plus read access
Tables Every table needs a primary key, or ALTER TABLE ... REPLICA IDENTITY FULL Tables without a primary key work, but sync more slowly
Other A free replication slot Binary logs kept for at least 24 hours
Provider To turn it on
Supabase, DigitalOcean, Render Usually ready; use the postgres / admin user
Neon Enable Logical Replication in the project settings
AWS RDS / Aurora PostgreSQL Set rds.logical_replication = 1 in the parameter group and reboot
AWS RDS MySQL / MariaDB Turn on automated backups (this enables the binary log), then run CALL mysql.rds_set_configuration('binlog retention hours', 72);
Google Cloud SQL Set the cloudsql.logical_decoding flag (PostgreSQL)
Azure Set wal_level to logical in the server parameters (PostgreSQL)
Heroku Postgres, PlanetScale Sync isn’t possible on these providers; use One-time copy

MySQL syncs into MySQL and MariaDB into MariaDB.

While it syncs

Section titled “While it syncs”
  • Schema changes (new tables or columns) made on your old database aren’t synced. Make them after switching over.
  • On PostgreSQL, DockHive adds a publication and a replication slot to your old database while the sync runs. They’re removed when you switch over or stop the sync. If your old database can’t be reached at that moment, the console shows the SQL to remove them yourself: run it, because a forgotten replication slot makes PostgreSQL keep its logs and fill its disk.
  • Sequences (auto-increment IDs) are moved to the right values when you switch over, so new rows don’t collide.

Engines and versions

Section titled “Engines and versions”
Your database Imports into
PostgreSQL 10 or newer DockHive PostgreSQL, same major version or newer (the check suggests 17, or 18 for PostgreSQL 18)
MySQL 5.7 or 8.x DockHive MySQL 8.0 or 8.4
MariaDB 10.x or 11.x DockHive MariaDB 10.11 or 11.4

Importing into the same family (MySQL into MySQL, MariaDB into MariaDB) is safest; the check warns you when the families differ. Other engines (Redis, MongoDB and others) can’t be imported yet.

MySQL isn’t offered in the us region yet. Pick another region for MySQL, or use MariaDB in us.

Follow the copy

Section titled “Follow the copy”

The Migration tab shows each step: Connecting, Copying (data copied so far, tables done, the table being copied), Verifying and Done. You can leave the page; the import keeps running. Click Cancel import to stop it.

When it’s done you get a report with the row count of every table on both sides. Very large tables are compared on estimates and marked as such. A difference usually means the source changed during the copy.

Then copy the database’s connection string from its Overview and put it in your app.

If something goes wrong

Section titled “If something goes wrong”

If an import fails or you cancel it, the DockHive database is emptied again automatically, so you can fix the problem and retry. Common messages:

Message What to do
The source database could not be reached Check the host and port, and allow the address shown in the check in your provider’s firewall.
The user name or password was rejected Check the user and password in the connection string.
TLS settings don’t match Your server doesn’t accept the encryption setting. Add sslmode=require (PostgreSQL) or ssl-mode=REQUIRED (MySQL) to the connection string, or match your provider’s setting.
This address is private Use your database’s public host name. Private and internal addresses can’t be reached from DockHive.
This database is not empty Import into an empty database, or choose to replace everything in it.
The extension … is not available Your database uses an extension DockHive doesn’t offer yet (for example vector). Objects that use it can’t be copied.

What is and isn’t copied

Section titled “What is and isn’t copied”
  • Copied: every table, its data and indexes, views, functions and procedures, triggers, sequences, types, and the extensions your database uses (when DockHive offers them).
  • Not copied: users, roles and their grants (your DockHive database user owns everything); MySQL DEFINERs become your DockHive user.
  • Provider-internal schemas (for example Supabase’s auth, storage and realtime) are unticked in the check. You can include them, but objects that point into a schema you don’t copy (for example a foreign key to auth.users) are skipped.
  • PostgreSQL: DockHive databases come with PostGIS installed. An import replaces that with exactly the extensions your source has. Run CREATE EXTENSION postgis; afterwards if you need it.

Limits

Section titled “Limits”
  • The source can use at most 90 % of the database’s storage. The check suggests a size; increase the storage first if needed.
  • One import at a time per database, and up to 20 imports per day.
  • An import can run for up to 6 hours.
  • Connection checks are limited to 60 per hour.
  • TLS is used by default. If your connection string turns it off (sslmode=disable, ssl-mode=DISABLED), the copy isn’t encrypted and the check warns you.

Provider notes

Section titled “Provider notes”
Provider Tip
Supabase Use the direct connection string (port 5432), not the pooler. Internal schemas are unticked automatically.
Neon Use the connection string from the dashboard; it already includes sslmode=require.
AWS RDS / Aurora Make the instance publicly accessible and allow DockHive’s address in its security group.
Heroku Use the database’s DATABASE_URL credentials.
PlanetScale Create a password with read access and use the MySQL connection string.
Railway / Render / DigitalOcean Use the external (public) connection string, and add DockHive’s address to the trusted sources where the provider has an allow list.

With the API

Section titled “With the API”
Terminal window
# Check a source (returns version, size, tables, warnings, blockers and the address to allow)
curl -X POST "https://api.dockhive.io/api/v1/databases/import/check?region=$REGION" \
  -H "Authorization: Bearer $DOCKHIVE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"connection_string": "postgresql://reader:[email protected]:5432/app?sslmode=require"}'


# Start an import into an empty database (add "replace": true to replace its contents)
curl -X POST "https://api.dockhive.io/api/v1/databases/$DB/import?region=$REGION" \
  -H "Authorization: Bearer $DOCKHIVE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"connection_string": "postgresql://reader:[email protected]:5432/app?sslmode=require"}'


# Follow it (state: queued, connecting, copying, syncing, switching, verifying, succeeded, failed or cancelled)
curl "https://api.dockhive.io/api/v1/databases/$DB/import?region=$REGION" \
  -H "Authorization: Bearer $DOCKHIVE_API_KEY"


# Keep in sync instead of a one-time copy: add "mode": "sync" to the check and the start
# Switch over once it's in sync
curl -X POST "https://api.dockhive.io/api/v1/databases/$DB/import/switchover?region=$REGION" \
  -H "Authorization: Bearer $DOCKHIVE_API_KEY"


# Cancel it (also stops a sync)
curl -X POST "https://api.dockhive.io/api/v1/databases/$DB/import/cancel?region=$REGION" \
  -H "Authorization: Bearer $DOCKHIVE_API_KEY"

You can also pass the source as fields instead of a connection string: {"engine": "mysql", "host": "...", "port": 3306, "database": "shop", "username": "reader", "password": "...", "ssl": true}. For PostgreSQL, "schemas": ["public", ...] picks the schemas to copy (default: the ones the check ticks).

Your source password is only used for the import: it’s stored encrypted while the import or sync runs, deleted when it ends, and never shown again.