Fix Error Establishing a Database Connection on Hostinger

You just migrated your WordPress site to Hostinger, updated DNS, loaded the homepage, and got slammed with a blank screen reading Error establishing a database connection. Don’t panic and start randomly changing passwords. It usually takes under ten minutes to fix once you isolate whether the issue is bad credentials, a messed-up host socket, or mismatched table prefixes.

WordPress throws this error whenever PHP fails to talk to MySQL or MariaDB. Following a migration, the cause is almost always an outdated string in wp-config.php or an unimported table prefix. Here is the exact checklist I run through to pinpoint the breakdown and get the site running again.

1. Why Migrations Trigger Database Connection Errors on Hostinger

When you migrate across hosts, database naming conventions change. Your old server might have let you name your database wp_site with a user like root or admin. Hostinger’s hPanel assigns an account-specific prefix to every database and user on shared and cloud hosting plans, usually formatted like u123456789_dbname.

Whether you used a migration plugin or followed our guide to migrate a large WordPress site to Hostinger with SSH and WP-CLI, the SQL import might have succeeded while your config file was left pointing to old or malformed credentials.

First, check where the error happens. If /wp-admin/ loads but says “One or more database tables are unavailable”, MySQL is alive, but your tables are corrupted or missing. If you see “Error establishing a database connection” everywhere, PHP can’t connect to MySQL at all.

2. Verify Your Database Credentials in wp-config.php

Start with the basics: check the core database constants in wp-config.php. You can edit this file through Hostinger’s File Manager in hPanel or directly via SSH in your public_html directory.

Open wp-config.php and look for these four lines:

/** The name of the database for WordPress */
define( 'DB_NAME', 'u123456789_production' ); /** MySQL database username */
define( 'DB_USER', 'u123456789_dbuser' ); /** MySQL database password */
define( 'DB_PASSWORD', 'YourStrongPassword123!' ); /** MySQL hostname */
define( 'DB_HOST', 'localhost' );

As noted in the official WordPress wp-config.php documentation, a single stray space, an unclosed quote, or a typo in these definitions will immediately kill the connection. Make sure the password string is wrapped in single quotes and isn’t truncated.

3. Cross-Check Database Details in Hostinger hPanel

Don’t assume you remember the database name or password—verify them directly in hPanel.

1. Log into Hostinger hPanel and open your website dashboard.
2. Go to Databases → Management.
3. Scroll down to List of Current MySQL Databases And Users.
4. Check that the full MySQL Database name matches DB_NAME in your config.
5. Check that the full MySQL User name matches DB_USER.

The most common mistake here is dropping the account prefix. If hPanel lists your database as u492019482_wp814, putting define('DB_NAME', 'wp814'); will fail every time. You need the full string with the prefix.

If you aren’t 100% sure about the password, click the three dots next to the database user in hPanel, hit Change Password, set a new one, and paste that exact string into DB_PASSWORD inside wp-config.php.

4. The DB_HOST Trap: Localhost vs. IP vs. Remote Sockets

On Hostinger shared and cloud plans, MySQL runs on the same server instance as PHP, so define('DB_HOST', 'localhost'); is standard. But depending on PHP’s MySQL socket configuration, resolving localhost can occasionally fail while 127.0.0.1 succeeds.

If localhost isn’t connecting, try swapping in the loopback IP with the explicit MySQL port:

/** Alternative DB_HOST configurations */
define( 'DB_HOST', '127.0.0.1' ); /** Or with explicit MySQL port if running custom instances */
define( 'DB_HOST', '127.0.0.1:3306' );

If you’re running WordPress on a Hostinger VPS (using Docker or separate database containers), localhost resolves inside the web container. In that case, you’ll need to supply the container service name or internal bridge IP instead.

5. Test MySQL Connectivity with a Standalone PHP Script

Instead of refreshing WordPress and wondering if caching layers or active plugins are muddying the output, write a tiny standalone script to test raw connectivity to MySQL.

Drop a temporary file named db-test.php into your public_html/ folder:

connect_error) { echo '
Connection Failed: ' . htmlspecialchars($conn->connect_error) . '
'; echo 'Error Code: ' . $conn->connect_errno . '
';
} else { echo '
Database connection established successfully!
'; echo '
MySQL Server Version: ' . $conn->server_info . '
'; $conn->close();
}
?>

Load https://yourdomain.com/db-test.php in your browser. If it fails, reference the PHP mysqli connect error documentation to decode the error code:

• Error 1045 (Access denied): Bad username or password.
• Error 1049 (Unknown database): Database name doesn’t exist or wasn’t created in hPanel.
• Error 2002 (Connection refused / socket error): MySQL isn’t running or DB_HOST isn’t resolving properly.

Important: Delete db-test.php immediately after testing so you don’t expose your database credentials to the web.

6. Check SSH Terminal and WP-CLI Connectivity

If you have SSH enabled on your Hostinger plan (found under Advanced → SSH Access), you can test database connectivity much faster from the terminal without opening a browser.

SSH into your server, navigate to public_html, and run:

# Test direct MySQL login
mysql -u u123456789_dbuser -p -h localhost u123456789_production # If using WP-CLI inside public_html
cd ~/public_html
wp db check

If wp db check prints all your tables with an OK status, the core database connection is working. If it throws an error, inspect what values WP-CLI is actually reading from your configuration:

wp config get DB_NAME
wp config get DB_USER
wp config get DB_HOST

Once you get things working, consider setting up automated backups by following our tutorial on how to automate WordPress backups with WP-CLI and Cron on Hostinger so you have a quick fallback next time you migrate.

7. Fix Table Prefix Mismatches in wp-config.php

I see this all the time: credentials match perfectly, the standalone PHP script connects, but WordPress still gives you a database error. That usually means your $table_prefix doesn’t match the table names in your imported SQL dump.

Check the prefix line in wp-config.php around line 65:

/** * WordPress Database Table prefix. * You can have multiple installations in one database if you give each * a unique prefix. Only numbers, letters, and underscores please! */
$table_prefix = 'wp_';

Now open phpMyAdmin from hPanel and look at your actual table names:

• If your tables are named wp_posts, wp_options, etc., the prefix must be wp_.
• If your old host or security plugin renamed them to something like wp_xyz123_posts, update your config to match:

$table_prefix = 'wp_xyz123_';

If the prefix doesn’t match character-for-character, WordPress connects to MySQL, looks for wp_options, fails to find it, and either errors out or tries to initiate a fresh installation.

8. Repair Corrupted Tables After Import

If an SQL

import was interrupted or got tripped up by character set differences (like utf8mb4_unicode_ci vs. utf8mb4_unicode_520_ci), specific tables might be locked or damaged. WordPress has an emergency repair utility built right in.

Add this line to wp-config.php just above /* That's all, stop editing! Happy publishing. */:

define( 'WP_ALLOW_REPAIR', true );

Save it, then open https://yourdomain.com/wp-admin/maint/repair.php in your browser and click Repair Database.

WordPress will loop through your core tables and execute repair statements. As soon as it finishes and the site is accessible, remove that line from wp-config.php immediately. Leaving it active lets anyone trigger database repairs without logging in.

9. Clear Stale Object Caching

If the site had Redis or Memcached enabled on the previous server, WordPress might still be attempting to query a local cache daemon that no longer exists, causing connection timeouts that look like database crashes.

Check your wp-content/ folder for a leftover drop-in file:

# Temporarily disable object cache drop-in
cd ~/public_html/wp-content
mv object-cache.php object-cache.php.bak

If you want to re-enable Redis caching on your new Hostinger plan properly, check out our guide on how to configure Redis Object Cache on Hostinger for faster WordPress.

Frequently Asked Questions

Why does Hostinger show “Error establishing a database connection” only on wp-admin?

When the frontend works (often served from page cache or Cloudflare) but /wp-admin/ crashes, it usually points to a corrupted user table—typically wp_users or wp_usermeta. Running a database repair or executing REPAIR TABLE wp_users; in phpMyAdmin usually fixes it.

Can SSL or mixed content cause a database connection error?

No. SSL handshake issues trigger browser security warnings or 502/521 errors, but they don’t break the local PHP-to-MySQL connection. If you hit mixed content issues after your database is back up, see our guide on how to fix SSL mixed content in WordPress with WP-CLI and .htaccess.

What MySQL privileges does the Hostinger database user need?

Your DB_USER needs full privileges: SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, and LOCK TABLES. In hPanel, users created under Databases → Management get full permissions automatically.

Is the database host ever a remote IP on Hostinger shared plans?

No. On shared and cloud plans, the database host is always localhost or 127.0.0.1. The Remote MySQL section in hPanel is only for letting external machines connect to Hostinger—your hosted WordPress site connects locally.

Next Steps

Once your site is back up, clean up after yourself: delete any test scripts like db-test.php and remove WP_ALLOW_REPAIR from wp-config.php. If you migrate sites regularly and want to bypass manual credential headaches next time, check out our full walkthrough on how to migrate large WordPress sites to Hostinger using SSH and WP-CLI.