Importing and exporting large databases

phpMyAdmin has an upload limit tied to PHP's upload_max_filesize and a script timeout tied to max_execution_time, so it's fine for small databases but unreliable once you're past a few hundred MB. For anything large, use mysqldump over SSH to export and import: it has no size cap, runs as fast as your disk and CPU allow, and doesn't time out mid-transfer.

Exporting a large database

If your plan includes SSH access, connect and run:

You'll be prompted for the database user's password. For a compressed export (recommended for anything over a few hundred MB):

If you don't have SSH on your plan, phpMyAdmin can still work for medium-sized databases: go to the database, click Export, choose Custom, and select gzip compression to cut the file size. If the export itself times out before finishing, that's the max_execution_time limit, not a hard block. You can raise it from Services → your hosting → PHP tile, described in increasing the maximum file upload size, which also covers post_max_size and memory_limit if the export process gets killed for using too much RAM.

cPanel's Backup Wizard as an alternative

If you only need a full copy of one database without SSH, cPanel's Backup Wizard (under Files) can generate a downloadable database-only backup. Open cPanel via the cPanel tile on your hosting service, as covered in accessing cPanel. This is a simpler path than mysqldump if you don't need control over the export flags, but it's slower to reach for repeated exports since there's no command to script.

Importing a large database

Create an empty database first (if it doesn't already exist), then import with:

For a gzipped file, pipe it through zcat instead of decompressing first:

This runs entirely on the server, so there's no upload step and no PHP limit involved. It's the reliable route for anything phpMyAdmin chokes on.

If SSH isn't available on your plan, phpMyAdmin's importer supports partial/resumed imports for large files. Split the SQL file into chunks (most dump tools have a chunking option, or use split on the file yourself) and import them in sequence.

Charset and collation surprises

The most common import failure isn't size, it's charset mismatch. Symptoms: question marks or garbled characters where accented letters or emoji used to be, or an import that succeeds but the data reads wrong afterward.

• Check what charset the dump was created with. Older dumps often default to latin1; modern applications (and most current WordPress/PHP apps) expect utf8mb4.
• Force the charset on both ends. When dumping: mysqldump -u dbuser -p --default-character-set=utf8mb4 dbname > dbname.sql. When importing: mysql -u dbuser -p --default-character-set=utf8mb4 dbname < dbname.sql.
• If the target database was created with a different default collation than the source, tables can import cleanly but sort or compare strings incorrectly. Check the database's collation in phpMyAdmin's Operations tab and match it to the source before importing, or run an ALTER DATABASE dbname CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; after.
• Emoji and some multi-byte characters need utf8mb4 specifically, not plain utf8, which MySQL's older "utf8" alias only stores 3 bytes per character for. If emoji are turning into question marks, this is almost always why.

Fixing charset after the fact, once bad data is already in the tables, is much harder than getting it right at import time. If a dump's origin charset is unknown, open the .sql file in a text editor and check the CREATE TABLE statements near the top, they usually declare it explicitly.

Before you import: back up what's there

An import that replaces or merges into an existing database can't be easily undone if something goes wrong halfway through. Take a manual backup first from the Backups tile, or generate one with cPanel's Backup Wizard, so you have a restore point. Our own daily backups (see our backup options) cover accidental loss too, but a fresh on-demand backup right before a risky import is worth the extra minute.

When to contact support

If mysqldump connections keep dropping mid-export on a very large database, or an import fails with errors you can't trace to charset or syntax, open a ticket from the portal (Support → New ticket) or use live chat. It's a real person, not a bot, and they can check server-side logs and connection limits you can't see from the client side.