phpMyAdmin Export Times Out on Large Database – Real Fix

When This Happens

You're sitting there, clicked "Export" in phpMyAdmin for your 200MB WordPress database or maybe a client's 1.2GB CRM dump. The browser spinner spins. Then nothing. Blank page, or a "504 Gateway Timeout," or just a partial file that's maybe 12MB when it should be 400MB. It happens nearly every time with databases over 50–100MB, especially on shared hosting or low-memory VPS boxes. I've had clients lose half a day on this because they thought their server was broken.

Root Cause – Plain English

phpMyAdmin is a PHP script running inside your web server. When you hit Export, it tries to pull the entire database into memory, format it as SQL, and stream it to your browser in one big PHP process. PHP has three settings that kill this: max_execution_time (often 30 seconds), memory_limit (often 128MB or 256MB), and max_input_time. Once PHP hits those ceilings, it just stops. No error message worth a damn – just a dead export.

The real fix is to either give PHP enough runway or bypass phpMyAdmin entirely. Don't waste time with browser tricks; the server is the bottleneck.

The Fix – Step by Step

Step 1: Bump PHP Limits (The Quick Fix)

If you have access to php.ini, edit it. On cPanel/WHM, it's often at /usr/local/lib/php.ini. On a typical Ubuntu LAMP stack, it's /etc/php/8.1/apache2/php.ini (adjust version). Change these:

max_execution_time = 600
max_input_time = 600
memory_limit = 512M
post_max_size = 256M
upload_max_filesize = 256M

Then restart Apache: sudo systemctl restart apache2 or sudo service httpd restart. This gives phpMyAdmin 10 minutes to export and 512MB of memory. For databases under 1GB, that's usually enough. If your DB is bigger, go to 1024M and 1800 seconds.

Step 2: Use Direct Export with Compression (Still in phpMyAdmin)

Even after bumping limits, don't export raw. In phpMyAdmin, check "Compressed" under Output (gzip or zip). This cuts the download size dramatically – a 200MB SQL dump often drops to 20MB. Also, uncheck "Add DROP TABLE / VIEW / PROCEDURE / FUNCTION" if you don't need it; it reduces output size. Pick "Custom" method, then under Format-specific options, choose "None" for data to avoid extra overhead. Run the export again.

Step 3: If Still Fails – Use mysqldump via SSH (The Real Fix)

Skip phpMyAdmin entirely. SSH into your server and dump it straight from MySQL. You'll get the file faster and with zero browser timeout nonsense. Run this:

mysqldump -u username -p database_name > /tmp/database_backup.sql

Replace username and database_name with your actual MySQL credentials. It'll ask for the password. Then download the file with SCP or SFTP. For a compressed version (much smaller):

mysqldump -u username -p database_name | gzip > /tmp/database_backup.sql.gz

Had a client last month whose 800MB WordPress DB export kept dying in phpMyAdmin. Took me 2 minutes with mysqldump.

Step 4: For Shared Hosting Without SSH – Use phpMyAdmin in Steps

If you're stuck on shared hosting (no SSH), export one table at a time. In phpMyAdmin, select the database, go to the "Export" tab, choose "Custom – display all possible options." Under "Tables," uncheck all, then check only a few tables (e.g., wp_posts, wp_options), export them. Repeat for the rest. This keeps each export small enough to not timeout. It's tedious, but it works.

What to Check If It Still Fails

Is MySQL timing out? Check wait_timeout in MySQL config (default 28800 seconds – fine usually). But if you hit it, it's not the cause unless you have absurdly long exports.
Web server timeout? Nginx or Apache might have their own timeouts. Nginx's proxy_read_timeout and fastcgi_read_timeout default to 60 seconds. Bump them to 600 in your server block or vhost config. Restart after.
Are you using a VPN or slow connection? If your internet drops mid-export, you'll get a partial file. Use wget on the server itself to export locally.
Is the database corrupted? Run mysqlcheck -u username -p database_name to check tables. A corrupt table can hang the export. Fix with mysqlcheck --repair.
Try a tool like Adminer – it's a single PHP file, lighter than phpMyAdmin, and often handles bigger exports better.

Bottom line: phpMyAdmin is convenient for small stuff, but for real work on big databases, use the command line. It's faster, more reliable, and you can script it for backups. Don't fight the browser – meet the server where it lives.