“Error establishing a database connection” means WordPress could not reach the database that holds your site. The message is the same for very different problems, which is why the standard advice — check your wp-config credentials — fixes only about half the cases, and often the wrong half. The fastest way in is one question: did anything change? If you or a migration edited the site, it is the credentials. If the site was fine and you touched nothing, it is the database server.
Below is what the message actually means, that first question in detail, a table matching each cause to the signal that points to it, and the fix. If it is a live shop and every page is down, skip to when it is not worth fixing it yourself.
What the message actually means
WordPress keeps your content — posts, pages, users, WooCommerce orders — in a MySQL database. On every page load it opens a connection to that database using four values in wp-config.php: the database name, the user, the password, and the host. When the connection fails, WordPress cannot build the page, so it shows the same generic line no matter why it failed.
That is the trap. The message tells you that the connection failed, never why. According to WordPress’s own documentation, it is “usually caused by an error in your wp-config.php file” or by not being able to contact the database server at DB_HOST — two completely different problems wearing the same error. Your data is not lost either way: it is sitting in the database, waiting for a connection that works.
The first question: did anything change?
Before touching anything, answer one question honestly, because it splits the causes cleanly in two.
If you (or a migration) changed something → credentials
Credentials in wp-config.php do not rot on their own. If the error appeared right after you edited that file, changed a database password, or moved the site to a new host, the cause is one of the four values being wrong for the new environment. On a fresh migration the usual culprit is not the password at all but DB_HOST: the value that was “localhost” on the old server needs to be something else on the new one.
If nothing changed → the database server
This is the half the generic guides skip. If the site was working and you edited nothing, re-checking credentials that were correct yesterday is wasted time. WordPress’s documentation is blunt about the alternative: your database may have “met its quota and been shut down”, or the server is simply down. On shared hosting the most common version is a database that ran out of resources or connections under load — which is why this error so often comes and goes instead of staying. Wrong credentials fail every time. A tired server fails only when it is busy.
Match the cause to its signal
Each cause leaves a different fingerprint. Match the signal you are seeing to the cause and the fix, rather than trying everything at once.
| Likely cause | The signal that points to it | The fix |
|---|---|---|
| Wrong credentials | Error appeared right after you edited wp-config.php or changed a DB password; fails every time | Re-check DB_NAME, DB_USER, DB_PASSWORD against what the host panel shows |
| Wrong DB_HOST after a move | Credentials are right but it still fails on a freshly migrated site | Change DB_HOST from localhost to 127.0.0.1, the host’s hostname, or add the port |
| Database server down or out of resources | Site was working, you changed nothing; the whole site is down at once | Contact the host — the database has hit its quota, run out of resources, or been shut down |
| Too many connections under load | Error spikes with traffic and clears when it drops — it comes and goes | Cut database load (caching, fewer heavy plugins) or move to a plan with a higher connection limit |
| Corrupted tables | wp-admin shows “One or more database tables are unavailable. The database may need to be repaired” | Enable WP_ALLOW_REPAIR, run the repair page, then remove the line — or repair in phpMyAdmin |
The fix, step by step
Work in this order. Back up wp-config.php and the database before you change anything — you need FTP or your host’s file manager, and access to the hosting panel.
1. Confirm the four credentials
Open wp-config.php and find these four lines. Check each against what your hosting panel shows for the database (name, user, password) — a single wrong character is enough.
define( 'DB_NAME', 'your_database' );
define( 'DB_USER', 'your_user' );
define( 'DB_PASSWORD', 'your_password' );
define( 'DB_HOST', 'localhost' );If you just created or imported the database, make sure the user is actually assigned to it in the panel. A correct name and password still fail if the user has no permission on that database.
2. If credentials are right, try DB_HOST
On most servers DB_HOST is localhost, but not all. If the site was just moved and everything else checks out, change localhost to 127.0.0.1. If that still fails, your host uses a specific database hostname or a non-standard port — their documentation lists the exact value. This is the most common reason a migrated site throws the error while the old one was fine.
3. If nothing changed, it is the server
If the credentials were correct and untouched, stop editing files. Load the hosting panel or status page: is MySQL running, is the account over its disk or database quota, is the server under load. This is a support ticket to your host, not another line in wp-config.php. Editing a file that is already correct only adds a second problem.
4. If wp-admin says tables need repair
When the front end shows the connection error but wp-admin shows “One or more database tables are unavailable. The database may need to be repaired”, the tables are corrupted, not unreachable. Add this line to wp-config.php:
define( 'WP_ALLOW_REPAIR', true );Then visit /wp-admin/maint/repair.php, run “Repair Database”, and — this part matters — delete the line afterwards. While it is set, that repair page is reachable by anyone, logged in or not. If repair does not help, the same job can be done in phpMyAdmin from your host panel.
When it is not worth fixing it yourself
The honest part. If you just edited wp-config.php or moved host, the fix is yours: correct the four values, sort out DB_HOST, done. You do not need us for a typo in a password.
Where do-it-yourself stops being worth it is the server-side and recurring version. If the site was untouched and the error is on the database server, the fix is on the host’s side, not in any file you can edit — and if it keeps coming back, that is not a fix you apply once, it is a capacity or a load problem that needs the database and the queries looked at properly. Repairing corrupted tables on a live shop is the other case to be careful with: get it wrong and a recoverable problem becomes a restore-from-backup afternoon. That is what our WordPress error-fixing service is for — back up first, find whether it is credentials, the server or corruption, fix that one thing. If instead your site shows a blank white screen or a WordPress critical error, those are different problems with different fixes.
Frequently asked questions
Does this error mean my site is hacked or my data is lost?
No. It means WordPress cannot reach its database right now — not that anything was deleted. Your posts, pages, media and WooCommerce orders are still in the database; once the connection or the credentials are fixed, they all come back. A hacked site looks different: admin accounts you did not create, spam pages, unexpected redirects.
The site was working and I changed nothing — why now?
Because the credentials in wp-config.php do not change on their own. If you genuinely touched nothing, the cause is almost always on the database server: it is down, has run out of resources, or hit a connection limit under load. That is a question for your host, not a wp-config edit.
The error comes and goes — what does that tell me?
An intermittent error is the signature of an overloaded database server, not wrong credentials. Wrong credentials fail every single time; a server short on resources fails only under load and recovers when the load drops. It usually means the site — or a neighbour on shared hosting — is exhausting the database connections.
What is DB_HOST supposed to be?
Usually “localhost”. Some hosts require “127.0.0.1”, a specific hostname, or a non-standard port. If the username and password are right but the connection still fails on a freshly migrated site, DB_HOST is the field to change — your host documents the correct value for their servers.
What does “One or more database tables are unavailable” mean?
That is the companion message WordPress shows in wp-admin when the tables exist but are corrupted rather than unreachable. It points to repair, not credentials: add WP_ALLOW_REPAIR to wp-config.php, run the repair page, then remove the line again.
Should I just restore a backup?
Only if the tables are genuinely corrupted and repair fails, and only from a backup you trust. If the cause is the server being down or a wrong credential, restoring a backup changes nothing and can overwrite recent orders or posts. Fix the connection first; a restore is the last resort, not the first.
Sources (verified July 2026): WordPress Developer — Common WordPress errors; WordPress Developer — Editing wp-config.php (DB_HOST, WP_ALLOW_REPAIR); WordPress — Common WordPress errors.