How to Fix the Error Establishing a Database Connection in WordPress

If your site shows a plain page that says “Error establishing a database connection”, WordPress can’t talk to the database where all your content lives. The good news: your content is almost always still there. I’ll explain the three things that cause the error, how to tell which one you have in a few minutes, and the fixes I use for each. You’ll also learn why the error sometimes comes and goes, which is a different problem from one that sticks.

What “error establishing a database connection” really means

Every WordPress page is built on the fly. PHP asks the database for your posts, settings and menus, then assembles the page. When that request fails at the very first step, WordPress has nothing to show, so it prints this one line and stops.

In my experience the cause falls into one of three buckets:

1. Wrong connection details. The database name, user, password or host in wp-config.php no longer match what the server expects.
2. The database server is down or overloaded. The details are right, but MySQL isn’t answering, or it is refusing new connections because it’s too busy.
3. A damaged database. WordPress connects, but key tables are corrupted.

A quick clue: if the front end shows the error but /wp-admin shows a message saying one or more database tables are unavailable, you’re probably in bucket three. If both show the same error, look at buckets one and two first.

Step 1: Check whether the database server is up

Before editing anything, rule out the host. This takes two minutes.

• Check your host’s status page or support chat for an outage.
• If you have other sites on the same hosting account, see if they’re down too. If all of them are, it is almost certainly the server.
• Open phpMyAdmin or the database tool in your hosting panel. If it won’t load or can’t connect, the database service itself is the problem.

If the server is down, your job is to report it, not to fix it. Give the host the exact time the error started and your domain. Don’t start changing passwords or restoring backups during a host outage. You can make a working site broken that way.

Step 2: Check the credentials in wp-config.php

This is the most common cause after a migration, a host change or someone “tidying up” the hosting panel. Open wp-config.php in your file manager and find these four lines:

• DB_NAME: the database name.
• DB_USER: the database user.
• DB_PASSWORD: that user’s password.
• DB_HOST: usually localhost, but some hosts use a specific hostname or add a port.

Compare each value with what your hosting panel shows under its database section. Watch for these traps:

• Someone changed the database user’s password in the panel and never updated wp-config.php.
• The database user exists but is not assigned to the database, or lacks privileges. In cPanel you have to add the user to the database as a separate step.
• The site was moved and the host uses a prefix on database names, such as an account name followed by an underscore.
• The password contains a single quote, which breaks the PHP line. Pick a strong password without quotes.

The fastest test is to log in to phpMyAdmin with the exact user and password from wp-config.php. If that login fails, you have found your problem. Reset the password in the panel, paste the new one into wp-config.php, and save.

While you’re in the file, check the $table_prefix line. If it says wp_ but the tables in phpMyAdmin start with something else, WordPress will act like a fresh, empty install or fail entirely.

Step 3: Repair a damaged database

If the credentials work and the server is up, a corrupted table is the next suspect. Take a database backup first, even a broken one. Then:

1. Add define('WP_ALLOW_REPAIR', true); to wp-config.php above the line that says to stop editing.
2. Visit yourdomain.com/wp-admin/maint/repair.php.
3. Click “Repair Database”. The optimize option takes longer and isn’t needed for the fix.
4. Remove the line from wp-config.php as soon as you are done. That page works without a login, so leaving it open lets anyone run it.

You can also select tables in phpMyAdmin and choose “Repair table”. If repair fails on core tables, restoring the database from your most recent clean backup is usually the safer path.

When the error comes and goes

An error that appears for a few minutes and then clears is a different story. The details are fine. The database is simply overwhelmed. Common reasons:

• A traffic spike or aggressive bots hitting pages that aren’t cached.
• Slow database queries from a heavy plugin, often search, related posts or reporting tools.
• A bloated wp_options table loading large amounts of data on every request.
• Shared hosting limits on connections that a busy site has outgrown.

The fixes are page caching, blocking bad bots at Cloudflare or the firewall, removing or replacing the slow plugin, and cleaning up autoloaded options. Sometimes the honest answer is that the site needs better hosting. A proper speed and performance cleanup usually reduces database load so much that the error stops.

One more cause to rule out: if the connection details changed and nobody on your side changed them, consider whether the site was compromised. Look for unknown admin users and recently changed files. If anything looks wrong, read up on WordPress malware removal before you restore anything.

The short version

• Check the host’s status and any other sites on the same account.
• Confirm you can open phpMyAdmin.
• Compare DB_NAME, DB_USER, DB_PASSWORD and DB_HOST with your hosting panel.
• Log in to phpMyAdmin with the exact details from wp-config.php.
• Check that the table prefix matches the tables.
• Back up, then run the WordPress repair tool and remove the repair line afterward.
• If the error is intermittent, look at caching, bots and slow plugins.

Worth reading next: how to fix the WordPress critical error safely and how to fix the WordPress white screen of death, step by step.

FAQ

Have I lost my website content?

Almost never. The error means WordPress cannot reach the database, not that the database is empty. Once the connection works, your content shows up again.

Why does the error only show up at busy times?

Because the database runs out of capacity. Uncached pages, bots and slow plugins use up connections. Caching and a performance cleanup usually fix it.

Should I just restore a backup?

Not first. If the cause is wrong credentials or a host outage, a restore won’t help and may overwrite recent orders or form entries. Diagnose, then restore only if the database is damaged.

Can a plugin cause this error?

Indirectly. A plugin can’t change your credentials on its own unless something is wrong, but a heavy plugin can overload the database and trigger the intermittent version.

If you would rather hand this to someone who has seen every version of it, I can find the cause and fix it on a backup first. Get a free website review, or read more about my WordPress error fixes.