Fix ‘Error Establishing a Database Connection’ on Hostinger WordPress

You open your WordPress site and get hit with a blank white screen and five dreaded words: Error establishing a database connection. Both your frontend and wp-admin are completely dead because PHP can’t talk to MySQL or MariaDB.

I ran into this exact headache recently after migrating a client site over to Hostinger and tweaking database privileges. In this guide, we’ll walk through how to figure out if you’re dealing with bad credentials in wp-config.php, a mismatched host address, corrupted database tables, or the Linux Out-Of-Memory (OOM) killer terminating MySQL in the background.

Why Hostinger Throws Database Connection Errors

WordPress needs four pieces of information to connect to MySQL: the database name, username, password, and host address. If even one character is off—or if the database service itself went down—the connection handshake fails instantly.

On Hostinger, the issue almost always boils down to one of these four problems:

• Credential mismatches: The password or username in wp-config.php doesn’t match what’s set in hPanel.
• Wrong database host: Shared hosting usually runs on localhost, but VPS setups or custom containers might need an explicit IP or socket binding.
• Corrupted tables: A botched update, hard reboot, or filled disk crashed critical tables like wp_options.
• OOM memory kills (VPS/Cloud): MySQL ate too much RAM during a traffic spike, so the Linux kernel killed the mysqld process.

Step 1: Verify wp-config.php Credentials in hPanel

First step: make sure your credentials actually match. Head into Hostinger hPanel, go to Databases → Management, and look at your active database name and user.

Next, fire up the hPanel File Manager (or SSH/SFTP in), navigate to public_html, and open wp-config.php.

Find the database configuration block around lines 20–40:

// ** Database settings - You can get this info from your web host ** //
define( 'DB_NAME', 'u123456789_prod' );
define( 'DB_USER', 'u123456789_dbuser' );
define( 'DB_PASSWORD', 'YourSuperSecretPassword123!' );
define( 'DB_HOST', 'localhost' );
define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );

Double-check these values against hPanel. Keep in mind: Hostinger auto-prefixes database names and usernames with an account ID (like u123456789_). Leaving off that prefix is the single most common mistake I see.

If you’re not 100% sure about the password, just reset it in hPanel under Databases → Change Password, then update DB_PASSWORD in your wp-config.php. Check the WordPress wp-config.php documentation if you’re using custom table prefixes or multisite.

Step 2: Test the Connection with a Standalone PHP Script

Before touching core files or plugins, let’s isolate whether the issue is with WordPress or the raw PHP-to-MySQL connection.

Drop a temporary file named check-db.php into your public_html folder with this code:

connect_error) { die('Connection Failed: (' . $mysqli->connect_errno . ') ' . $mysqli->connect_error);
} echo 'Database connection succeeded! MySQL server version: ' . $mysqli->server_info;
$mysqli->close();
?>

Open https://yourdomain.com/check-db.php in your browser. If it fails, take a look at the error code (see the PHP mysqli construct manual for details):

• Error 1045 (Access Denied): Wrong username or password, or the user lacks permissions for that database.
• Error 1049 (Unknown Database): The database name is wrong or wasn’t created.
• Error 2002 (Connection Refused): MySQL isn’t running or the host/socket path is wrong.
• Connection succeeded: Your credentials work fine. The issue is corrupted tables or a plugin conflicting with database calls.

Important: Delete check-db.php as soon as you’re done testing so you don’t expose raw database credentials to the web.

Step 3: Fix Database Host and Socket Mismatches

On Hostinger shared and cloud plans, DB_HOST should almost always be set to localhost. But if you’re running a Hostinger VPS with Nginx and MySQL separated, or using custom Unix sockets, localhost might try (and fail) to connect via a missing socket file.

If your test script threw a socket error like No such file or directory, change DB_HOST in wp-config.php from localhost to the loopback IP:

// Force TCP connection over 127.0.0.1 instead of Unix domain socket
define( 'DB_HOST', '127.0.0.1' );

If your MySQL daemon is running on a non-standard port (like 3307), append the port directly:

define( 'DB_HOST', '127.0.0.1:3307' );

If you recently switched DNS or proxy layers, take a look at our guide on how to fix WordPress 504 gateway timeout errors to verify traffic is actually hitting your origin server.

Step 4: Repair Corrupted Database Tables

If your credentials work but you see messages like “One or more database tables are unavailable”, you’ve likely got corrupted tables—often triggered by an aborted update or full disk.

WordPress has a built-in repair tool. To turn it on, add this line to wp-config.php right above /* That's all, stop editing! Happy publishing. */:

define( 'WP_ALLOW_REPAIR', true );

Save it, then visit this URL in your browser:

https://yourdomain.com/wp-admin/maint/repair.php

Click Repair Database (or Repair and Optimize Database). WordPress will run through tables like wp_posts, wp_options, and wp_usermeta to rebuild damaged indexes.

Once it finishes, delete that line from wp-config.php. Leaving it enabled lets anyone trigger database repairs on your server without logging in.

If you have SSH access, you can run the repair faster using WP-CLI:

# Navigate to site root and run database repair
cd /var/www/html/public_html
wp db repair --allow-root
wp db optimize --allow-root

If table recovery fails completely, you’ll need to restore from a backup. Here’s how to import a large WordPress database via SSH cleanly.

Step 5: Verify MySQL User Privileges

A database user might exist with the right password, but still lack permissions to run queries on that specific database. This happens a lot after manual database migrations or creating users inside phpMyAdmin.

In Hostinger hPanel:

1. Head to Databases → Management.
2. Scroll down to List of Current Databases and Users.
3. Confirm the user is explicitly linked to the database.
4. If permissions look messed up, unlink the user and re-assign them with All Privileges.

On a Hostinger VPS, you can check user grants straight from the MySQL CLI:

# Log into MySQL as root
mysql -u root -p # Check grants for your WordPress user
SHOW GRANTS FOR 'u123456789_dbuser'@'localhost';

If the user is missing permissions, grant full access and flush privileges:

GRANT ALL PRIVILEGES ON u123456789_prod.* TO 'u123456789_dbuser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Step 6: Handle MySQL Crashes and OOM Kills on Hostinger VPS

If you’re on a Hostinger KVM VPS and the connection drops intermittently during traffic spikes, MySQL is almost certainly running out of RAM and crashing.

SSH into your server and check the system logs to see if the Linux kernel OOM killer took down MySQL:

# Check dmesg for OOM kill events
dmesg -T | grep -i -E 'killed process|oom_reaper|mysqld' # Check MySQL / MariaDB service status
systemctl status mysql --no-pager

If you see Out of memory: Kill process (mysqld), your server ran out of physical memory. Adding swap space and tuning PHP worker limits will stabilize it.

First, check if you have active swap space:

# Check current swap allocation
free -h

If swap is 0B, allocate and enable a 2GB swap file:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile # Make swap persistent across reboots
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

After that, tune your PHP limits so workers don’t hog all the RAM. Check our guide to increase WordPress PHP memory limit and max upload size on Hostinger.

Step 7: Tune the InnoDB Buffer Pool Size in MySQL

On a VPS with 1GB or 2GB of RAM, MySQL 8.0’s default InnoDB buffer pool is often too aggressive. You can clamp it down in your MySQL config file:

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Add or edit these lines under the [mysqld] block:

[mysqld]
innodb_buffer_pool_size = 256M
innodb_log_buffer_size = 16M
max_connections = 50
key_buffer_size = 16M

Save the file and restart MySQL to apply the changes:

sudo systemctl restart mysql

This keeps MySQL from fighting PHP-FPM and Nginx for system RAM, preventing random database drops when traffic spikes.

Frequently Asked Questions

Why does the error only show up on wp-admin but not the frontend?

If your frontend is cached by a CDN or Hostinger’s LiteSpeed Cache, visitors are seeing static HTML snapshots served from the cache layer. But accessing /wp-admin forces WordPress to run live PHP and query MySQL. Purge your cache or test an uncached URL to see if the whole site is down.

Can a plugin trigger ‘Error establishing a database connection’?

Yes. Resource-heavy plugins (like broken link checkers, analytics, or backup tools) can easily max out your database connection limits or query execution timeouts. Try renaming /wp-content/plugins to plugins-disabled via File Manager or SFTP to see if the site comes back up.

Does changing the database password break my content?

No. Changing the database user password only updates how PHP authenticates with MySQL. It doesn’t touch, modify, or delete your posts, pages, or settings.

What if my wp_options table is completely corrupted?

If wp db repair can’t fix wp_options, open phpMyAdmin from hPanel, select your database, check the box next to wp_options, and pick Repair table from the dropdown. If that still fails, roll back using Hostinger’s automated snapshots.

Next Steps for Securing Your Database Stack

Once your site is back online, set up a solid backup routine so you aren’t stuck troubleshooting next time. Here is how to automate WordPress backups with WP-CLI and Cron on Hostinger VPS so you can recover in minutes if a future update breaks things.