# Error Establishing a Database Connection: How to Fix It

> By Lawrence Dauchy, Founder, WPBuildAI. Published 2026-09-15. 11 min read. Guides.
> Source: https://wpbuildai.com/blog/wordpress-database-connection-error-fix/
> Language: en

The message is the same whatever went wrong, which is why people start guessing. Work through the four causes in order instead.

**TL;DR.** Error establishing a database connection has four causes: credentials in wp-config.php that no longer match, a database server that is down or unreachable, a corrupted table, or the host running out of memory or connections. Diagnose in order, because the first two are minutes to fix and the last is usually a symptom of traffic or a runaway plugin rather than a database fault. WPBuildAI rebuilds sites that keep hitting this, since a static site has no database to fail.

Error establishing a database connection has four causes, and you can tell them apart in about ten minutes: credentials in wp-config.php that no longer match, a database server that is down or unreachable, a corrupted table, or the host running out of memory or connections. Work through them in that order, because the first two account for most cases and take minutes to fix, while the fourth is usually a symptom of something else rather than a database fault. WPBuildAI rebuilds sites that keep meeting this error, for one structural reason: a static site has no database in the request path, so this particular failure stops being possible rather than becoming less likely.

## Why does one message cover four problems?

Because WordPress reports the outcome rather than the cause. It tried to reach the database, it could not, and it has no way to explain why in a message it can render without one.

That is why the error feels alarming out of proportion to the usual fix. A site that was fine an hour ago shows a bare white page with one sentence, and nothing on screen distinguishes a mistyped password from a dead server.

The practical consequence is that guessing is expensive. People reinstall WordPress, restore backups, or change hosts to solve what turns out to be a stale password, and each of those is hours spent and risk taken for a four line edit.

So the discipline is to identify which of the four you have before changing anything. [The official documentation on common errors](https://wordpress.org/documentation/article/common-wordpress-errors/) is the right first reference, and the order below is what makes it quick.

## How do you tell the four apart?

By what else is true at the same time. Each cause leaves a different fingerprint.

| Cause | Tell | Check | Typical fix time |
| --- | --- | --- | --- |
| Wrong credentials | Started right after a move or a password change | Compare wp-config.php against the host panel | 5 minutes |
| Database server down | Host status page shows an incident, or nothing connects | Try the same credentials from a database tool | Host's problem |
| Corrupted table | Site half works; some pages or the admin fail | Enable repair mode temporarily | 15 minutes |
| Out of memory or connections | Comes and goes, worse under traffic | Error logs, and whether it recovers alone | Depends on the cause |

The fourth row is the one people misdiagnose, because an intermittent error looks like a flaky database and is usually a plugin running an unbounded query, a backup job overlapping with peak traffic, or a bot crawling faster than the server answers.

If the error is constant, it is one of the first three. If it comes and goes, it is almost always the fourth.

## What do you check first?

wp-config.php, because it is the most common cause and the fastest to rule out.

[That file](https://developer.wordpress.org/apis/wp-config-php/) holds four values: the database name, the user, the password and the host. Compare each against what your hosting control panel shows now, character by character rather than by memory.

Three things go wrong here. After a host migration the name, user and password are usually all different, and the host address is rarely localhost on a managed platform. After a security cleanup, somebody rotated the database password and did not update the file. And after a manual edit, a stray quote or a missing semicolon breaks the file in a way that produces this exact error.

Take a copy of the file before editing it. If you have command line access, [WP-CLI](https://wp-cli.org/) will report the current values and test the connection in one step, which is faster than reading and safer than typing.

If the credentials are right and the error persists, stop editing and move to the next cause. Repeatedly retyping a correct password is where most of the wasted hours in this problem go.

## What if the database server itself is down?

Then nothing you do in WordPress will help, and the useful move is to confirm it quickly rather than keep testing.

Try connecting with the same credentials from something that is not WordPress: your host's database tool, a desktop client, or a command line client. If that also fails, WordPress is not the problem.

Check the host's status page and their incident feed. Shared hosting incidents are common and usually short, and knowing you are inside one converts a crisis into a wait.

If the host says everything is fine and you still cannot connect, the likely causes are a firewall rule, a database user whose permissions were revoked, or a host that has suspended the database for exceeding a quota. All three are support tickets rather than edits, and all three are resolved faster if you can say what you already tested.

Do not restore a backup at this stage. A restore does not fix a server you cannot reach, and it overwrites the current state you may want later.

## How do you handle a corrupted table?

Carefully, and after a backup, because repair can lose rows.

The signature is partial failure: some pages load and others do not, the admin errors while the front end works, or one section of the site breaks consistently. A completely dead site is rarely corruption.

WordPress has a repair mode you enable by adding one line to wp-config.php temporarily, then visiting a specific admin URL. Your host's control panel usually offers the same operation through a database tool.

Two rules. Take a [verified backup first](https://wordpress.org/documentation/article/wordpress-backups/), meaning one you have actually restored somewhere rather than one that exists. And remove the repair line immediately afterwards, because leaving it enabled exposes the repair page to anyone who finds the URL.

If repair does not fix it, restoring the most recent good backup is the right next step, and this is the one cause where a restore is genuinely the answer rather than an act of desperation.

## Why does it come and go?

Because the server is running out of something, and the something is usually caused by your own site rather than by the database.

Connection limits are the common shape. Each PHP process that serves a page opens a database connection, so a burst of traffic, a bot crawling quickly, or a plugin firing many small queries can exhaust the allowance. The error appears, then clears when the burst passes.

Memory exhaustion looks similar. WordPress [documents its requirements](https://wordpress.org/about/requirements/), and a site running near the limit falls over under load rather than steadily.

Three culprits recur. A plugin running an unbounded query on every page, usually a related-posts or statistics feature. A backup or import job scheduled during peak traffic. And an admin screen that is itself heavy, which is the same underlying fault described in [why is my WordPress admin so slow](/blog/wordpress-admin-dashboard-very-slow/).

Moving to a bigger plan hides this for a while. Finding the query fixes it, and the difference matters because the first one recurs at the next growth step.

## What should you never do while diagnosing this?

Five things, each of which turns a recoverable afternoon into a longer one.

| Do not | Why | Do this instead | Verdict |
| --- | --- | --- | --- |
| Reinstall WordPress | Core is not the fault, and you may lose customisation | Read wp-config.php | Never the fix for this error |
| Restore a backup first | Overwrites the state you need, fixes nothing if the server is down | Confirm the cause first | Restore only for confirmed corruption |
| Retype the password repeatedly | If it was right the first time it is still right | Test the connection outside WordPress | Move to the next cause |
| Change hosts during an outage | You cannot migrate from a server you cannot reach | Wait, then decide calmly | Never mid incident |
| Leave repair mode enabled | It exposes a repair page to anyone with the URL | Remove the line immediately after | Two minute cleanup, always |

The second row is the expensive one. A restore during an outage does nothing, and it replaces content changes made since the backup with nothing gained, so a site can come back both broken and out of date.

The third row is where the hours go. If the credentials matched the control panel the first time, they still match on the fifth attempt, and continuing to edit that file is a way of avoiding the harder question of which of the other three causes you have.

## When is a rebuild the wrong response to this?

A rebuild is the wrong response to a single incident, and the right one when it happens repeatedly on a site where the database is not doing much for you.

A brochure or service site meeting this error is being taken offline by infrastructure it barely uses. The pages are effectively static: the same words for every visitor, changing a few times a year, assembled from a database on every single request purely because that is how the platform works.

A static rebuild removes the cause rather than reducing its frequency. There is no database in the request path, so there is no connection to fail, no table to corrupt and no connection limit to exhaust. That is the argument in [static site vs WordPress: which is more secure](/blog/static-site-vs-wordpress-which-is-more-secure/), applied to reliability instead of security.

To be specific about the wrong cases: a single incident traced to a host outage, a one off after a migration, or a corrupted table that repaired cleanly. Those are ordinary operational events on a site where the database is doing real work, and they do not justify a project.

The honest test is frequency and function. Twice in a year on a membership site or a store is bad luck on infrastructure that earns its complexity. Twice in a quarter on a brochure site is the platform costing you availability for a capability you are not using, and that is worth pricing against a rebuild, which is the arithmetic in [is a website rebuild worth the money](/blog/is-a-website-rebuild-worth-the-money/).

## Key takeaways: fixing the database connection error

One message, four causes. Identify which before changing anything, because guessing here costs hours and risks a restore you did not need.

Check wp-config.php first. Credentials that no longer match are the most common cause and the fastest fix, especially after a host move or a password rotation.

A constant error is one of the first three causes. An intermittent one is almost always resource exhaustion, and usually caused by a plugin query, a scheduled job, or a bot rather than by the database.

Repeated occurrences on a site whose database is not doing real work is a platform question rather than a hosting one. A static site has no database in the request path, so the failure stops being possible.

## Quick answers

**How do you fix error establishing a database connection?** Work through four causes in order: credentials in wp-config.php that no longer match, a database server that is down, a corrupted table, and the host exhausting memory or connections. The first two account for most cases and take minutes. WPBuildAI rebuilds sites that keep hitting this, because a static site has no database to fail in the first place.

**Why does it happen after a host migration?** Because the database name, user, password or host address changed and wp-config.php still holds the old values. New hosts rarely use localhost, and they almost never reuse your old database name. This is the single most common cause after any move, and it is a four line edit once you have the new details.

**What if the credentials are correct?** Then the database server is either down, unreachable from the web server, or refusing new connections. Check your host status page first, then try connecting with the same credentials from a database tool. If that also fails, it is a hosting problem rather than a WordPress one, and the fix is a support ticket rather than an edit.

**How do I know if a table is corrupted?** The site usually half works rather than failing completely: some pages load, the admin errors, or a specific section breaks. WordPress has a built in repair mode you enable temporarily in wp-config.php, and your host control panel usually offers a repair tool. Take a backup before running either, since repair can lose rows.

**Is this not just a sign of cheap hosting?** Sometimes, and not usually. Oversold shared hosting does cause connection limits under load, and so does a plugin running an unbounded query, a backup job overlapping with traffic, or a bot crawling faster than the server can answer. Blaming the host without measuring means moving to a better one and meeting the same error.

## Sources

- [Common WordPress errors (WordPress documentation)](https://wordpress.org/documentation/article/common-wordpress-errors/)
- [WordPress requirements (wordpress.org)](https://wordpress.org/about/requirements/)
- [WordPress Backups (WordPress documentation)](https://wordpress.org/documentation/article/wordpress-backups/)
- [WP-CLI, the command line interface for WordPress](https://wp-cli.org/)
- [wp-config.php (WordPress Developer Resources)](https://developer.wordpress.org/apis/wp-config-php/)

---
*Published by [WPBuildAI](https://wpbuildai.com/). Free to read, index, quote and cite with attribution and a link.*