Guide Databases & MySQL

How to import a database too large for phpMyAdmin

A file too big for a browser upload still has three practical ways in — compression, splitting, or the command line.

iFastHosting Support Team Updated 26 August 2026 8 min read Intermediate

phpMyAdmin's import is a browser upload followed by a script that has to finish inside a fixed time limit, and both of those have a ceiling. A database with years of WordPress post revisions, a large e-commerce order history, or an application's log tables can easily produce a SQL file that clears both limits before you have even reached the interesting part of the import. The good news is that none of this makes the data un-importable — it just rules out doing it in one click through the browser.

Work through these in order

1. Compress the file

This is worth trying before anything more involved, because it is the least effort for the biggest possible gain. A raw SQL export compresses extremely well — plain text full of repeated keywords like INSERT INTO is exactly what gzip is good at — and a file that looked hopeless uncompressed sometimes drops comfortably under the limit once compressed.

gzip dbname.sql

phpMyAdmin accepts .sql.gz and .zip files directly and decompresses them automatically during import, so there is no extra step at the other end. If this gets the file under the upload limit, you are done — go back to importing a database with phpMyAdmin and proceed as normal.

2. Import over SSH with the mysql command

If SSH access is available on your account — offered on some hosting tiers and standard on a VPS or dedicated server — the mysql command-line client has no browser upload limit and no fixed script timeout, because it runs directly on the server rather than through a web request.

mysql -u dbuser -p dbname < dbname.sql

For a compressed file, decompress on the way in without writing an uncompressed copy to disk first:

gunzip < dbname.sql.gz | mysql -u dbuser -p dbname

Both commands prompt for the password rather than taking it as plain text, and both write directly into an existing database — create it and attach a user first if you have not already, following creating a MySQL database and user.

Run it inside screen or tmux for a genuinely large file

A very large import can take a long time, and an SSH session that drops partway through leaves you unsure how much actually completed. Running the command inside a screen or tmux session lets the import keep running on the server even if your own connection is interrupted, and you can reconnect to check on it.

3. Split the file if SSH is not available

Without SSH access, the remaining option is to break the single large file into smaller pieces and import each one through phpMyAdmin in turn. A SQL export is a sequence of complete statements, so it can be split at statement boundaries without breaking anything, provided you cut cleanly between statements rather than through the middle of one.

In practice this usually means either exporting table-by-table instead of the whole database in one file — phpMyAdmin's Custom export lets you select specific tables — or using a text editor capable of handling a large file to divide it manually at clean breaks. Import each piece in turn, in the same order they were exported, since later statements can depend on tables created earlier in the sequence.

Splitting badly is worse than not splitting at all

A file cut through the middle of an INSERT statement produces a syntax error on import and can leave a table partially populated with no clear record of where it stopped. If you are not confident doing this by hand, exporting table-by-table from the start is a safer way to end up with several smaller, individually valid files.

What does not help

Raising upload_max_filesize or max_execution_time yourself is usually not possible on shared hosting, because these are server-level settings rather than per-account ones — and even where they can be adjusted, there are limits to how far a shared environment can reasonably raise them for one account. Do not spend time hunting for a way to override them from within phpMyAdmin itself; there is not one, by design.

If none of this is practical

For a database large enough that none of the above feels manageable — tens of gigabytes, for instance, in a full migration — contact us with details of what you are moving and from where. Server-side transfers and imports handled directly, without going through a browser or a personal connection at all, are often the more sensible route once a database reaches that size, and it is worth asking rather than fighting a file that was never a good fit for a manual import in the first place.