How to Fix "Error Establishing a Database Connection" in WordPress

This message is more specific than it looks. PHP executed, WordPress loaded, and then the database handshake failed. That narrows the problem to three things: wrong credentials, a database server that is not answering, or damaged tables.

1. Check the credentials in wp-config.php

Open wp-config.php and compare these four values against what your hosting panel shows:

define( 'DB_NAME', 'your_database' );
define( 'DB_USER', 'your_user' );
define( 'DB_PASSWORD', 'your_password' );
define( 'DB_HOST', 'localhost' );

Three things go wrong here more than anything else:

• You migrated the site and carried over the old host's credentials. Every value usually changes on a move.
• DB_HOST is wrong. localhost is right on most shared hosting, but managed and cloud hosts often need a specific hostname or 127.0.0.1:3306. Your panel will state it.
• Someone reset the database password in the panel and did not update the file.

If the credentials look right, prove it. Put this in a file called dbtest.php in the site root:

<?php
$c = @new mysqli('localhost', 'your_user', 'your_password', 'your_database');
echo $c->connect_error ? 'FAILED: '.$c->connect_error : 'CONNECTED OK';

Load it in a browser. "CONNECTED OK" means your credentials are fine and the problem is elsewhere. Delete the file immediately afterwards — it contains your database password in plain text.

2. Check whether the database server is up

If the credentials test fails with something like "Can't connect to MySQL server", the database itself is the problem, not WordPress. Common reasons:

• MySQL crashed or was killed — often out of memory on a small VPS. Restarting the service brings the site straight back, but if it recurs, the server needs more memory or MySQL needs tuning.
• You hit a connection limit. Shared hosts cap simultaneous connections. A traffic spike, or a plugin opening connections it never closes, will exhaust them. The site typically recovers on its own and then fails again.
• Disk full. MySQL refuses writes when the volume fills. Check free space first on any self-managed server; it is a surprisingly frequent cause and gives confusing symptoms.

On a server you control, systemctl status mysql or systemctl status mariadb answers this in one command.

3. Repair corrupted tables

If the connection works but the site still errors, or the admin says "one or more database tables are unavailable", run WordPress's own repair tool. Add this to wp-config.php:

define( 'WP_ALLOW_REPAIR', true );

Then visit https://yoursite.com/wp-admin/maint/repair.php. Note that this page is deliberately accessible without logging in, which is why you must remove the constant as soon as you are done.

Choose "Repair Database" first. Use "Repair and Optimize" only if you have a backup — optimising rewrites tables and takes much longer on a large database.

When only the front end is broken

If /wp-admin loads but the public site does not (or the reverse), the cause is usually a cached page or an object cache holding a stale connection, not the database. Purge Redis or Memcached if you use one, and clear your caching plugin.

Preventing the repeat

• Keep a note of database credentials somewhere other than the server they belong to.
• On a VPS, add swap. Most "MySQL keeps dying" reports are an out-of-memory kill on a box with no swap configured.
• Watch for plugins that write heavily to the database on every page load — visitor loggers, unbounded activity logs, statistics plugins that never prune. They are the usual reason a small site starts exhausting connections.
• Take database backups that you have actually tested restoring.