Import Large WordPress Databases via SSH on Hostinger

Trying to upload a 500MB or 2GB database dump through phpMyAdmin on shared hosting almost always ends in heartbreak—usually a 413 Request Entity Too Large or a dead-end 504 Gateway Timeout. Don’t fight the web interface. Upload the raw SQL file directly to your Hostinger account and restore it over SSH in seconds.

Browser buffers, PHP memory caps, and Nginx timeout limits will sabotage you every time on a large file. The command line skips the entire HTTP stack and pipes your SQL dump straight into MariaDB or MySQL without arbitrary web server timeouts.

Enable SSH Access in hPanel and Connect

Hostinger turns SSH access off by default on new accounts. You need to flip the switch in hPanel before your terminal will connect.

Log in to hPanel, head to Advanced > SSH Access, and toggle it on. You’ll see your connection details right there: IP address, port, username, and password.

Watch that port number closely. Hostinger doesn’t use the standard port 22 on shared or cloud accounts—they route everything through custom port 65002.

Open your local terminal and test the connection:

ssh -p 65002 u123456789@195.154.122.45

Replace u123456789 and the IP address with the exact credentials from your hPanel dashboard. If you use SSH keys, paste your public key directly into the SSH Access screen in hPanel so you don’t have to retype your password every session. For more on connection security, check the Hostinger SSH setup documentation.

Transfer the SQL Dump to Your Hostinger Account

Never push an uncompressed .sql file over SCP if you can avoid it. A bloated 3GB plain text dump usually compresses down to around 350MB with gzip, saving you tons of transfer time.

First, compress your database dump locally if you haven’t already:

gzip -9 production_backup.sql

This spits out production_backup.sql.gz in your local directory.

Now ship the archive up to your remote home directory using scp. Notice the uppercase -P for SCP’s custom port (unlike the lowercase -p SSH uses—this trips everyone up at least once):

scp -P 65002 production_backup.sql.gz u123456789@195.154.122.45:~/

Drop the file into your root user folder (~/), not into public_html. Keeping database dumps out of your web root prevents scrapers or visitors from downloading your entire database if an Nginx or .htaccess rule misfires. If you prefer syncing files in bulk alongside themes and media, check out our guide to migrate WordPress to Hostinger via SSH and rsync.

Locate Your WordPress Database Credentials

You need the exact database name, user, and password to run the import. Instead of digging through hPanel, grab them straight from your existing setup on the server.

SSH into your Hostinger account, jump into your site directory, and inspect the configuration file:

cd ~/domains/yourdomain.com/public_html
grep -E 'DB_NAME|DB_USER|DB_PASSWORD|DB_HOST' wp-config.php

The terminal will print lines structured like this:

define( 'DB_NAME', 'u123456789_prod' );
define( 'DB_USER', 'u123456789_admin' );
define( 'DB_PASSWORD', 'SuperSecretPassw0rd!' );
define( 'DB_HOST', 'localhost' );

Jot these down. On Hostinger shared and cloud plans, DB_HOST is almost always localhost, but double-check your config just in case it points to a specific internal hostname.

Import the SQL Dump via Native MySQL CLI

The fastest, most reliable way to restore your database is streaming it directly into the native mysql client.

You don’t even need to decompress the gzip file on the server first. Pipe gunzip right into mysql. It saves disk space, which matters on quota-capped hosting plans:

gunzip < ~/production_backup.sql.gz | mysql -u u123456789_admin -p u123456789_prod

Hit Enter and paste the DB_PASSWORD string from your wp-config.php. The terminal will look frozen—that’s completely normal while MySQL chugs through queries.

If you already have an uncompressed .sql file, run the traditional file redirect:

mysql -u u123456789_admin -p u123456789_prod < ~/production_backup.sql

On a recent migration with a 1.8GB dump containing 4.2 million rows across WooCommerce logs and post meta, this import finished in 38 seconds flat. That exact file crashed phpMyAdmin after spinning out for seven minutes.

Alternative: Import Using WP-CLI

Hostinger has WP-CLI installed out of the box on its servers. If your wp-config.php is already configured and points to your empty database, you can skip typing credentials altogether.

First, navigate into the directory containing WordPress:

cd ~/domains/yourdomain.com/public_html

If you have an uncompressed file, invoke the official WP-CLI db import tool:

wp db import ~/production_backup.sql

WP-CLI reads wp-config.php, handles the connection authentication behind the scenes, and runs the import. You’ll see this confirmation when it finishes:

Success: Imported from '~/production_backup.sql'.

If the target database already has leftover tables from a default one-click WordPress install, wipe them clean before importing so you don’t run into prefix collisions:

wp db reset --yes
wp db import ~/production_backup.sql

Fixing Common Import Errors

Big migrations rarely run cleanly on the first try. Here are the three errors that bite people most often when importing into Hostinger, and how to fix them.

1. MySQL Server Has Gone Away (Packet Size Limit)

If your dump has giant serialized rows—like base64-encoded images in postmeta or massive builder settings—MySQL bails out if a single packet exceeds its buffer limit.

You don’t need root access to tweak my.cnf. Just bump the allowed packet size inline during the import:

mysql --max_allowed_packet=512M -u u123456789_admin -p u123456789_prod < ~/production_backup.sql

This allocates a 512MB payload buffer for bulky multi-row inserts. For more details on packet sizing, see the MySQL official documentation on max_allowed_packet.

2. Unknown Collation: utf8mb4_0900_ai_ci

This is a classic trap: your old host ran MySQL 8.0, but your Hostinger plan runs MariaDB 10.5 or 10.6. MariaDB doesn’t know what to do with MySQL 8’s default utf8mb4_0900_ai_ci collation, and the import crashes immediately.

Fix it with a quick sed search-and-replace on your uncompressed .sql file before importing:

sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_520_ci/g' ~/production_backup.sql
sed -i 's/utf8mb4_0900_as_cs/utf8mb4_unicode_520_ci/g' ~/production_backup.sql

This swaps the unsupported MySQL 8 collation for utf8mb4_unicode_520_ci across the entire file in seconds.

3. Memory Exhaustion During Decompression

If your SSH session drops out of nowhere while piping gunzip into mysql, you probably tripped Hostinger’s process memory cap. Uncompress the archive to disk first, then run the import directly:

gunzip ~/production_backup.sql.gz
mysql -u u123456789_admin -p u123456789_prod < ~/production_backup.sql

Post-Import Steps: Search-Replace and Cleanup

Once the dump imports, your site is still pointing at your old domain or staging URL. Whatever you do, don’t run a raw SQL UPDATE across your tables—it will mangle serialized PHP strings and break your theme settings and widgets.

Run a WP-CLI dry run first to see what’s going to change:

cd ~/domains/yourdomain.com/public_html
wp search-replace 'https://old-domain.com' 'https://new-domain.com' --dry-run

If the replacement count looks right, execute it across the database:

wp search-replace 'https://old-domain.com' 'https://new-domain.com'

For a complete breakdown of escaping and flags, read our guide on how to safely update URLs after WordPress migration with WP-CLI.

Next, clear your object cache and rewrite rules so WordPress generates fresh rewrites:

wp cache flush
wp rewrite flush

If your old database accumulated years of transient junk, clean up your options table using our walkthrough to clean up bloated wp_options autoload data with WP-CLI.

Finally, delete the database dump from your user directory so sensitive user hashes and customer emails don’t linger on disk:

rm ~/production_backup.sql
rm ~/production_backup.sql.gz

Preventing SSH Dropouts on Massive Files

If you’re dealing with a massive multi-gigabyte database on a Cloud plan, a momentary Wi-Fi hiccup will kill your SSH session. When the shell drops, your active import dies with it, leaving you with a half-populated, broken database.

If your environment doesn’t support screen or tmux, use nohup to detach the import completely:

nohup mysql -u u123456789_admin -p'SuperSecretPassw0rd!' u123456789_prod  ~/import.log 2>&1 &

Notice there’s no space between -p and your password when passing it inline. The trailing ampersand (&) backgrounds the job, and nohup prevents the process from receiving a SIGHUP (hangup) signal if your terminal disconnects.

Check the progress of your background import anytime by tailing the log:

tail -f ~/import.log

If the log file stays empty and the process exits with a status code of 0, the restore finished cleanly without errors.

Frequently Asked Questions

Can I use SSH on Hostinger Shared Web Hosting?

Yes. Hostinger includes SSH on their Premium and Business shared hosting tiers, as well as all Cloud and VPS packages. The baseline Single plan sometimes restricts SSH access, so verify that your plan includes it under hPanel’s Advanced menu.

Why does the mysql command show an ‘Access denied’ error?

Double-check that the database user is actually linked to that specific database inside hPanel. Go to Databases > Management, find your database, and verify the user exists and has full read/write permissions assigned.

How do I know when the import is complete?

When running mysql -u user -p dbname < file.sql interactively, the terminal won’t show a progress bar. When it finishes, the cursor returns to your standard shell prompt (like u123456789@server:~$). If you want real-time visibility, monitor table sizes in a second terminal tab or pipe it through pv if your tier has it installed.

Can I import a zipped (.zip) file directly?

No. MySQL can’t parse ZIP archives directly. You must extract the .sql file first using unzip file.zip, or compress your dump with gzip to use the streaming pipe method shown above.

Next Steps for Your Hostinger Migration

Now that your database tables are restored and URLs updated, verify your site health in the WordPress dashboard. Next, cut down background server load by replacing WordPress’s default pseudo-cron with a system task; follow our guide to disable WP-Cron and set up a real cron job in Hostinger.