“Error Establishing a Database Connection”: What It Actually Means

It's the most frightening message WordPress produces, because it sounds like your content is gone.

It almost never is.

WordPress stores your posts, pages, settings, and users in a MySQL database, and every page load fetches them. This error means WordPress couldn't complete that conversation — not that the conversation partner has died. Four things cause it, they're distinguishable in about five minutes, and three of the four are quick fixes.

The short version

Four causes, in order of likelihood:

1. Wrong credentials in wp-config.php — usually after a migration or host change
2. The database server is down or overloaded — usually the host's problem, not yours
3. Corrupted database tables — WordPress has a built-in repair tool
4. A genuinely deleted or damaged database — rare, and what backups are for

Your data is almost certainly intact. The error is about reaching the database, not about its contents.

Step 1 — Is it the whole site, or just the front end?

Try loading yoursite.com/wp-admin.

Both show the error → a connection problem. Continue below.

wp-admin shows a different message — something like "one or more database tables are unavailable, the database may need to be repaired" → jump to the table repair section. That message is WordPress telling you the connection works but the tables are damaged.

That single check splits your four causes in half, which is why it's first.

Step 2 — Check the credentials

The most common cause, and it almost always follows a change: a migration, a host switch, a password rotation, or someone tidying up database users.

Open wp-config.php via FTP or your host's file manager. Near the top you'll find:

define( 'DB_NAME', 'your_database_name' );
define( 'DB_USER', 'your_database_user' );
define( 'DB_PASSWORD', 'your_password' );
define( 'DB_HOST', 'localhost' );

Compare each against what your hosting control panel says under MySQL Databases or equivalent.

Where these go wrong:

The database name changed during migration. Hosts often prefix names with your account name, so mysite becomes user123_mysite.

The password is stale. A rotated database password that nobody updated in wp-config.php.

DB_HOST isn't localhost. It usually is on shared hosting, but plenty of hosts use a specific server address, and some use 127.0.0.1 or a named host. Check what your host documents — guessing here wastes time.

Invisible characters. If credentials were pasted from an email, a stray space or line break inside the quotes will break the connection while looking perfectly fine.

Fix any mismatch, save, and reload.

Step 3 — Is the database server actually up?

If the credentials are definitely right, the server itself may be down or refusing connections.

How to check:

Your host's status page. Look for a reported incident before doing anything else.

Try phpMyAdmin from your hosting control panel. If phpMyAdmin can't connect either, it's the server, not WordPress.

Check whether you've hit a connection limit. Shared hosting caps simultaneous database connections. A traffic spike, a badly-behaved plugin, or a neighbouring site on the same server can exhaust them — which produces this exact error, intermittently, and then resolves on its own.

The tell for a connection limit: the error comes and goes rather than persisting. Intermittent database errors are usually resource exhaustion, not configuration.

The fix is a support ticket. If it recurs, it's either a plugin generating excessive queries or a hosting plan you've outgrown.

Step 4 — Repair corrupted tables

If wp-admin gave you the "tables may need to be repaired" message, WordPress has a built-in tool for exactly this.

Add this line to wp-config.php, above the "stop editing" comment:

define( 'WP_ALLOW_REPAIR', true );

Then visit:

yoursite.com/wp-admin/maint/repair.php

You'll get "Repair Database" and "Repair and Optimize Database" options. Repair alone is faster; the combined option takes longer on a large database.

Then remove that line immediately. The repair page requires no login while the constant is enabled — anyone who finds the URL can run it. Delete it as soon as you're done.

If the built-in tool doesn't fix it, phpMyAdmin can repair tables directly: select the database, tick the affected tables, and choose "Repair table" from the dropdown.

Step 5 — When it's genuinely broken

If none of the above works, the database may have been deleted, corrupted beyond repair, or lost in a hosting failure.

This is what backups are for. Restore the most recent one, then work out what happened.

Before restoring, check whether your host keeps automatic backups — most managed hosts do, often more recent than yours.

And take a copy of the current state first, even broken. If the database is partly readable, a specialist may recover more than a restore would, and you can't do that once you've overwritten it.

Is my data lost?

Almost certainly not, and it's worth understanding why the reassurance is genuine rather than polite.

This error is about the connection, not the contents. Wrong credentials mean WordPress is knocking on the wrong door — everything behind the right door is untouched. A down server means the building is temporarily closed. Corrupted tables usually mean an index needs rebuilding, not that rows are gone.

Actual data loss requires the database to have been deleted or physically damaged, which is rare and generally accompanied by other obvious problems.

Confirm it for yourself: open phpMyAdmin from your hosting control panel and look at wp_posts. If your content is there, it's a connection problem and nothing more.

Preventing it

Note your database credentials somewhere secure when you set up or migrate a site. Half of these incidents are a five-minute fix that took two hours because nobody knew the details.

Update wp-config.php immediately whenever a database password changes.

Watch for intermittent errors. Occasional database errors under load are an early warning that you're outgrowing your hosting or running something inefficient. Auditing plugins.

Keep backups you've actually restored. An untested backup is a hypothesis. Doing backups properly.

Frequently asked questions

Why does this happen suddenly?
Usually because something changed that you didn't connect to your database — a migration, a host switch, a rotated password, or a hosting plan change. The other common cause is resource exhaustion, where a traffic spike or an inefficient plugin exhausts your allowed database connections. That version is intermittent rather than constant, which is the useful tell: a persistent error points to credentials, an on-and-off one points to load.

Can I fix it without a developer?
Usually, yes. Checking your credentials in wp-config.php against your hosting control panel takes about five minutes and resolves the most common cause. Running WordPress's built-in repair tool handles corrupted tables. Checking your host's status page identifies a server outage. The only scenario genuinely needing help is a damaged or deleted database with no usable backup.

Is my data lost?
Almost certainly not. The error means WordPress couldn't reach the database, not that its contents are gone. Wrong credentials, a down server, or corrupted table indexes all produce this message while your posts and settings sit intact. To confirm, open phpMyAdmin from your hosting control panel and look at the wp_posts table — if your content is there, it's purely a connection problem.

What to do next

Open wp-config.php and compare the four database constants against your hosting control panel. That's five minutes, and it's the cause more often than everything else combined.

If they match, check your host's status page before touching anything else. An outage you're troubleshooting around is an hour you don't get back.

Free: The WordPress maintenance checklist.

---

Related guides

• When WordPress breaks: a diagnostic order — the wider diagnostic
• Blank page after an update — if the timing points at an update
• WordPress backups — the restore path you'll eventually need
• WordPress plugin audit — reducing database load