Updated September 2026: when a database dump is too large for phpMyAdmin, the most reliable alternative is to upload the file to the server and pass it directly to the MySQL command-line client through SSH or cPanel Terminal.
The short version is:
mysql --default-character-set=utf8mb4 -u database_user -p database_name < /home/account/backup.sql
The -p option asks for the database password securely. Do not add the password directly to the command: it may be stored in shell history or exposed to another process.
When should you import a database through SSH?
Use SSH when phpMyAdmin rejects the upload, the browser times out, the dump is hundreds of megabytes or the import needs to run without keeping a browser tab open. The MySQL manual documents this input-file method, and WordPress administrators can also use the official WP-CLI database import command.
SSH does not remove server limits such as max_allowed_packet, storage quotas or database permissions. It removes the PHP upload and browser-request limits that commonly affect phpMyAdmin.
Before you start: safety checklist
- Create a fresh backup of the destination database, even if it appears empty.
- Confirm the target database name and user. Importing into the wrong database can overwrite an active site.
- Check that the SQL dump came from a trusted source and has a reasonable file size.
- Keep the dump outside
public_htmlwhenever possible so it cannot be downloaded from the web. - Confirm that the destination has enough free storage for both the SQL file and the imported database.
- If this is a migration, prepare the old and new site URLs before running any search-and-replace operation.
If you are moving an entire site, read our WordPress migration checklist before changing DNS or URLs.
Step 1: export a clean SQL dump
Export the database as an SQL file from the source host. A normal dump should contain statements such as CREATE TABLE and INSERT INTO. For a WordPress site, confirm that expected tables such as wp_options, wp_posts and wp_postmeta exist; the prefix may be different.
If the file is compressed as .sql.gz, you can import it without permanently extracting a second copy. ZIP archives normally need to be extracted first because the MySQL client cannot read them directly.
Step 2: create the database and user in cPanel
- Open MySQL Databases or the database management interface provided by your host.
- Create the destination database.
- Create or select a database user with a strong unique password.
- Add the user to the database and grant the privileges required for the import.
- Record the full cPanel-prefixed names. A database entered as
sitemay actually be namedaccount_site.
Do not assume that the cPanel account password is also the database password. Use the credentials assigned to that database user.
Step 3: upload the dump securely
Upload the file with SFTP or cPanel File Manager to a private directory such as:
/home/account/backups/backup.sql
Avoid leaving SQL dumps in public_html. They can contain user records, email addresses, password hashes, API settings and other private data. If the host only allows an upload into the web root, use a hard-to-guess temporary filename, complete the import promptly and delete the file immediately afterwards.
Step 4: open SSH or cPanel Terminal
Connect with your hosting account over SSH or open the Terminal interface under cPanel’s Advanced tools. Hosting providers can disable Terminal, so contact the host if it is not visible. cPanel describes Terminal as direct command-line access and warns that incorrect commands can affect the server.
Move to the directory containing the dump and confirm the file:
cd /home/account/backups
ls -lh backup.sql
Use pwd if you are unsure which directory is active.
Step 5: import the SQL file
For an uncompressed dump:
mysql --default-character-set=utf8mb4 -u account_dbuser -p account_database < backup.sql
For a gzip-compressed dump:
gzip -dc backup.sql.gz | mysql --default-character-set=utf8mb4 -u account_dbuser -p account_database
Some servers provide the MariaDB client under the mariadb command instead of mysql. The host can confirm which binary is available.
For a WordPress installation with working wp-config.php credentials, WP-CLI is often simpler:
wp db import /home/account/backups/backup.sql
WP-CLI reads the configured database credentials, but it does not create the database for you.
Step 6: verify the import
A command that returns to the prompt without an error is encouraging, but verify the result:
- Open phpMyAdmin and confirm the expected tables and approximate row counts.
- Check that the table prefix matches
$table_prefixinwp-config.php. - Load the site and test the homepage, login, forms and important account or checkout journeys.
- Review the PHP and database logs for errors.
- Delete the uploaded SQL file after the import is confirmed.
If the domain or path changed
WordPress stores URLs in the database, including serialized values. Do not run a raw SQL find-and-replace across every table. Use a serialization-aware tool and start with a dry run:
wp search-replace 'https://old.example' 'https://new.example' --all-tables-with-prefix --precise --dry-run
Review the count, then repeat without --dry-run only when the values are correct. Keep the original backup until the new site has been tested.
Common import errors
Access denied for user
Recheck the full database username, password, host and privileges. On shared hosting, database names and users commonly include the cPanel account prefix.
Unknown collation
The source may use a collation unsupported by the older destination database server. The safest fix is normally to use compatible server versions or export with compatible settings. Do not blindly replace collations without understanding the character-set impact.
Packet too large
A large individual statement can exceed max_allowed_packet. This is a server setting; ask the host to increase it or create a dump with smaller statements.
The command appears frozen
Large imports often produce no progress output. Check server activity in another session or use a utility such as pv if the host provides it. Do not interrupt the process simply because the cursor is quiet.
Tables already exist
The destination is not empty or the dump is being imported twice. Stop and confirm the target. Restore the pre-import backup or empty only the intended destination database before retrying.
Document the database handover and cleanup
After a successful import, record the source, destination, command used, validation result and person responsible for deleting temporary SQL files. Confirm that the old environment is retained only for the agreed rollback period and that its credentials are removed when the migration closes.
If the import is part of a complete site move, follow the WordPress migration checklist for files, URLs, redirects and launch monitoring. Ongoing issues should enter a defined WordPress support workflow rather than remaining with an individual developer.
Importing a large MySQL database FAQ
How large a database can I import over SSH?
SSH avoids browser and PHP upload limits, but the practical limit still depends on disk space, database configuration, account resource limits and the hosting provider.
Can I import a compressed SQL file?
Yes. A gzip file can be streamed with gzip -dc backup.sql.gz | mysql .... Keep the password prompt enabled and verify the exit result.
Is WP-CLI safer than the mysql command?
Both can be safe. WP-CLI is convenient for WordPress because it reads database credentials from wp-config.php. The MySQL client is more universal and works without WordPress.
Should I put the SQL file in public_html?
No, not when a private home directory is available. Database dumps can contain sensitive data and should not be publicly downloadable. Delete temporary copies after verification.
Need help with a database migration?
CodaStudio can back up, import and validate a WordPress database as part of a controlled migration or support task. See our WordPress support services or choose a care plan.
