Fix phpMyAdmin Import Errors on Large SQL Files in cPanel

You've got a 300MB (or 2GB) .sql file to bring into a cPanel database, so you open phpMyAdmin, click Import, pick the file, and hit Go. A few minutes later you're staring at a blank white page, a 500 error, or a red banner saying the file is too large. The database ends up half-populated, some tables present and others missing, and re-running the import just throws the same error. This isn't file corruption — phpMyAdmin simply wasn't designed to move big databases through a browser upload, and cPanel's default PHP limits make sure of it.

Symptom: Import Stalls, Times Out, or Silently Stops

The exact error you see depends on where the process fails, but it usually looks like one of these:

• You probably tried to upload a file that is too large — phpMyAdmin rejects it before the import even starts
• The browser tab spins for a while, then shows a blank page or a 500/502 error with no useful message
• The import appears to finish, but half the tables are missing when you check the database in phpMyAdmin afterward
• Fatal error: Allowed memory size exhausted partway through

None of these mean your dump file is bad. They mean something in the request chain gave up before the import could complete.

Cause: Several Limits Stack Up Against You

A phpMyAdmin import through the browser has to survive four separate checkpoints, and any one of them can kill it:

Raise every PHP value and you can still hit that last one, because phpMyAdmin enforces its own ceiling on top of PHP's. A dump with a few huge tables, a lot of INSERT statements, or large BLOB columns (stored images, for instance) chews through all of these fast, especially on shared or CloudLinux-limited accounts where LVE resource caps add another layer on top.

Fix 1: Raise the PHP Limits (Works for Small-to-Medium Files)

In cPanel, go to MultiPHP INI Editor, select the domain or PHP version tied to the database's application, and switch to Editor Mode. Bump these values:

upload_max_filesize = 512M
post_max_size = 512M
max_execution_time = 300
memory_limit = 512M

Save, then go back into phpMyAdmin, open Settings > Import, and check the ExecTimeLimit value there too — it's separate from PHP's and needs raising independently, or set to 0 for unlimited. This approach works fine up to a few hundred MB. Past that, you're fighting against the fact that a browser upload just isn't built for this, and you'll want Fix 2 instead.

Fix 2: Skip the Browser Entirely — Import via SSH

If your plan includes SSH access, this is faster and far more reliable than phpMyAdmin for anything over a couple hundred MB. Upload the .sql file via SFTP or SCP, then run:

mysql -u cpaneluser_dbuser -p cpaneluser_dbname < /home/cpaneluser/dumpfile.sql

No browser timeout, no upload cap, no memory ceiling tied to a web request — the command line process just runs until it's done. For WordPress specifically, if WP-CLI is available:

wp db import dumpfile.sql --path=/home/cpaneluser/public_html

For very large files, pipe through pv to watch progress, or run it inside screen or tmux so the import survives if your SSH session drops:

screen -S dbimport
mysql -u cpaneluser_dbuser -p cpaneluser_dbname < dumpfile.sql

Detach with Ctrl+A then D, and reattach later with screen -r dbimport to check on it.

Fix 3: No SSH? Compress or Split the Dump

On shared hosting without terminal access, two tricks shrink the problem instead of the limits:

• Gzip the file before uploading. phpMyAdmin can import .sql.gz directly, and compressed dumps are often 80–90% smaller than the raw SQL, which alone can get you under the upload cap.
• Split it into chunks. A tool like BigDump imports a large SQL file in small batches, one HTTP request at a time, so no single request ever gets close to the timeout. It's slower but works entirely inside a shared-hosting environment with no SSH.

If neither is an option, open a support ticket — on SkyServer accounts we can run the import directly from the server side, which sidesteps every browser-related limit at once.

Prevention: Make the Next Export Smaller

A few habits keep this from happening again on the next migration or restore:

• When exporting from phpMyAdmin, tick Compression: gzip instead of plain SQL — it's a one-click change that avoids most upload-size problems later.
• For WordPress databases, clear stale transients and check the size of wp_options before exporting; a bloated options table can add tens of megabytes of dead weight to every dump.
• Exclude tables you don't actually need to migrate — session tables, cache tables, and old log tables from plugins are common offenders.
• For anything over 200–300MB as a habit, default to mysqldump and mysql over SSH rather than phpMyAdmin, even if the file would technically fit under the raised limits.

Frequently Asked Questions

What's the actual maximum file size phpMyAdmin can import on cPanel?

There's no fixed number — it depends on whatever you set for upload_max_filesize, post_max_size, and phpMyAdmin's own ExecTimeLimit. In practice, most successful browser-based imports on shared hosting stay under 200–300MB even after raising limits, because execution time becomes the bottleneck before file size does.

Can I increase these limits myself, or do I need to contact support?

If you have access to MultiPHP INI Editor in cPanel, you can raise the PHP-level limits yourself. Some values, like server-wide execution time caps under CloudLinux LVE, may need a support request if your account is capped at the package level.

Why did my import "succeed" but half the tables are missing?

This almost always means the request hit a timeout or memory limit partway through, and phpMyAdmin's browser interface didn't clearly report the failure. Check the database table count against the original dump's CREATE TABLE statements to confirm, then re-import using the SSH or split-file method to avoid a repeat.

Is importing via SSH safe if I'm not comfortable with the command line?

Yes, the two commands in this guide are the entire process — connect, run mysql -u user -p dbname < file.sql, enter the password when prompted. There's no risk to existing data unless the target database already has conflicting table names, so import into a fresh or empty database when in doubt.

Does gzip compression change the SQL content in any way?

No. Gzip is lossless compression — the SQL statements inside are identical before and after. phpMyAdmin decompresses the file automatically during import, so there's no extra step needed on the receiving end.