Import and export a database

You can bring a database in by uploading a .sql or .sql.gz file of up to 2 GB, or by giving a link to one. The import shows its progress live, and says exactly where it stopped if something goes wrong. You can export a copy at any time: a gzipped dump, kept for 24 hours for you to download.

Import and export work for MySQL, MariaDB and PostgreSQL, shared or own. Valkey holds no tables, so it has neither.

Import a file

1. Open the database from your project's Overview.

2. Under Import and export, drop your .sql or .sql.gz file, or choose Choose a file.

3. Watch it upload, then import: the percentage, and the table being made.

Before an import starts, your project is backed up, so you can go back if it goes wrong: it's on the Backups tab as Before an import. See Backups and restore.

The upload goes in pieces. If your connection drops, choose the file again and it carries on from where it stopped, so a big file on a slow network still gets there. When it's done, the page says how many tables it imported. Stop the import stops it part way.

Import from a link

If your old host gives you a backup link, you don't need to download and upload it again:

1. Choose Import from a link.

2. Paste a link that starts with https:// or http://, to a .sql or .sql.gz file of up to 2 GB.

3. Choose Import.

The file is fetched from outside our own network, under the same outgoing rules as your apps.

We check what the file is

Before importing, we read the start of the file to see what it is:

• A MySQL or MariaDB dump, from mysqldump, mariadb-dump or phpMyAdmin's export.

• A PostgreSQL dump, from pg_dump in its plain format.

• Plain SQL, guessed from how it's written.

If the file is for another type of database, like a PostgreSQL dump going into MySQL, you're told before anything happens. Most of it won't import, so the best fix is to export the old database for the right type. You can still choose Import anyway. A PostgreSQL archive made with pg_dump -Fc is refused: export it again as plain SQL.

Example: Asha moves her WordPress database

Asha's old blog ran on cPanel. In phpMyAdmin she chose her database, then Export, and saved blog.sql. She gzipped it to blog.sql.gz, which is often a tenth of the size, so it uploads faster.

In duka she added a shared MySQL named blog, opened it, and dropped blog.sql.gz under Import and export. The page showed the upload, then "Importing blog.sql.gz… 64%" and "Making the table wp_postmeta". A minute later: imported, 12 tables. She opened Tables to check that wp_posts had all her posts.

When an import fails

The page shows what the database said, and the line of the file where it stopped. Common causes:

We remove a few things a dump often carries that a database user can't run, like DEFINER= clauses and GTID_PURGED, before they reach your database, so most dumps from cPanel and other hosts import as they are.

Your dump is kept safe from others, and others from it

A dump file is a list of commands, and some dump tools can run programs on the machine that reads them. So each import runs in a throwaway sandbox that reaches only your database, as your database's own user, never an administrator, with the import tool's shell and file commands switched off. The uploaded file is deleted when its import ends.

Export a copy

1. Under Import and export, choose Export a copy.

2. Watch the percentage. When it's ready, the page shows the file's name and size, like duka.sql.gz.

3. Choose Download.

The export is a normal dump from the database's own dump tool, gzipped. It's kept for 24 hours, then deleted, and only people in your account can download it. Export a copy before a risky change, like a big migration or a query that edits many rows.

To open it on your own computer, unzip it and load it with mysql or psql.