WordPress “Error Establishing a Database Connection”

You type your domain into the browser, hit enter, and instead of your homepage you’re staring at a blank white screen with one blunt line of text: “Error establishing a database connection.” No menu, no design, no content — just that sentence sitting on an otherwise empty page.

For a site owner, this is one of the more alarming errors WordPress can throw. It doesn’t point to a broken plugin or a missing image; it means WordPress can’t talk to the database where every post, page, product, and setting actually lives. Until that connection is restored, visitors see nothing, and neither do you when you try to log into wp-admin.

The good news is that this error is almost always fixable, and in most cases it doesn’t mean your content is gone. This guide walks through what causes it, how to diagnose it, and how to get your site back online — plus how to make sure it doesn’t happen again.

What This Error Actually Means

WordPress is really two things working together: the files that make up the theme and plugins, and a MySQL (or MariaDB) database that stores everything dynamic — your posts, users, comments, and configuration. Every time a page loads, WordPress reaches into wp-config.php, grabs the database credentials, and uses them to pull content from that database.

When you see the database connection error, one of three things has usually happened:

• WordPress has the wrong credentials for the database (or the credentials it has no longer work)
• The database server itself is down, overloaded, or unreachable
• The database itself is corrupted, often after an unclean shutdown, a bad migration, or a plugin update gone wrong

None of these mean your files or your database contents are permanently lost. They mean something in the connection chain is broken, and that chain can be repaired.

Common Causes

Incorrect database credentials. If your database name, username, password, or host changed — say, after a server migration or a hosting plan change — but wp-config.php still has the old details, WordPress simply can’t authenticate.

A corrupted wp-config.php file. A bad edit, a failed plugin install, or a botched manual update can leave this file malformed, even if the credentials inside it are technically correct.

Database server overload. On shared hosting especially, if too many connections hit the MySQL server at once, or the server itself hits a resource cap, WordPress gets refused a connection even though nothing is actually broken.

Corrupted database tables. Interrupted updates, abrupt server restarts, or disk issues can corrupt one or more of the tables WordPress relies on, most commonly wp_options.

Plugin or theme conflicts. Some plugins alter database queries or connection behavior in ways that occasionally break under specific server configurations.

Hosting-side outages. Sometimes the fault isn’t in WordPress at all — the database server on the hosting provider’s end is simply down.

How to Diagnose and Fix It, Step by Step

1. Check wp-config.php First

This is the most common culprit, and the fastest to rule out. Connect via FTP or your hosting file manager and open wp-config.php in the site’s root directory. Confirm these four values match what’s actually set up on your database server:

define( 'DB_NAME', 'your_database_name' );
define( 'DB_USER', 'your_database_username' );
define( 'DB_PASSWORD', 'your_database_password' );
define( 'DB_HOST', 'localhost' );

DB_HOST is worth double-checking specifically — many hosts use something other than localhost, and it’s an easy value to overlook. Your hosting control panel (cPanel, Plesk, or similar) will show the correct host, username, and database name under its database management section. If a password was reset at some point and never updated in this file, that alone explains the error.

2. Confirm the Database Exists and the User Has Access

In your hosting panel’s database section, verify the database itself is still there and that the listed user is actually assigned to it with full privileges. Migrations and hosting-plan changes occasionally leave a database orphaned from its user, which produces exactly this error even with a “correct-looking” wp-config.php.

3. Check Whether the Database Server Is Reachable

If the credentials all check out, the problem may be the server itself. A quick way to test this without touching code: create a small PHP file with a basic mysqli_connect() call using the same credentials and upload it to your site root, then load it in the browser. If it fails to connect, the issue sits with the database server, not WordPress — which usually means it’s time to contact your hosting provider.

4. Look for a Corrupted Database

WordPress has a built-in repair tool for exactly this situation. Add this line to wp-config.php, above the line that says /* That's all, stop editing! */:

define( 'WP_ALLOW_REPAIR', true );

Then visit yourdomain.com/wp-admin/maint/repair.php in your browser. You’ll get the option to repair, or repair and optimize, the database. Run it, then remove that line from wp-config.php again once you’re done — leaving it in place exposes the repair tool to anyone who finds the URL.

5. Rule Out a Resource Limit

On shared hosting, a spike in traffic or a runaway process (a poorly optimized plugin, a bot crawling aggressively) can max out the number of allowed database connections. This tends to show the error intermittently rather than constantly. If it comes and goes, ask your host whether the account hit a connection or resource limit around the time it started.

6. Check for Recent Changes

If the error appeared right after installing a plugin, running an update, or migrating hosts, that timing is a strong clue. Renaming the plugins folder via FTP (WordPress will then run with all plugins disabled) is a quick way to check whether a specific plugin is the trigger, without needing admin access.

7. Restore from a Recent Backup

If none of the above resolves it, or the database itself is too corrupted to repair, a recent backup — of the database, the files, or both — is the fastest way back to a working site. This is the point where having automated backups already in place, rather than scrambling for one after the fact, makes the biggest difference in how long the site stays down.

When It’s Worth Bringing in a Developer

Some of this is safe for a non-technical site owner to check — the credentials in wp-config.php, whether the database exists in the hosting panel. But repairing a genuinely corrupted database, tracing a resource-limit issue with a host’s support team, or untangling which of a dozen plugins caused the conflict is where things get riskier to do without experience, especially with a live, revenue-generating site on the line.

If your site is throwing this error right now, or you’d rather not find out the hard way what happens when a repair attempt goes wrong, getting a developer to fix the WordPress bug directly is usually faster and safer than trial and error. For sites where this kind of outage has happened more than once, ongoing WordPress maintenance — regular backups, update management, and monitoring — is what actually prevents the next one.

After the Fix: Reducing the Odds of a Repeat

Once the site is back up, it’s worth treating the incident as a signal rather than a one-off. A few things consistently reduce how often this error shows up:

• Automated, offsite backups of both files and the database, taken daily or before every update
• Staging environments for testing plugin and theme updates before they touch the live database
• Resource monitoring, especially on shared hosting, so a connection-limit issue is caught before it causes downtime
• Database optimization on a regular schedule, since bloated or fragmented tables are more prone to corruption

If downtime like this has hit your site more than once, or your database has grown large and slow over time, it’s also worth having a speed optimization pass done — a leaner, better-indexed database is both faster and more resilient. And because search engines penalize sites that go down or load slowly, even a short outage can have a lingering effect on rankings; folding in some SEO optimization work after a fix helps recover any ground lost during the downtime.

For site owners who are tired of this category of problem altogether — database errors, plugin conflicts, sudden white screens — moving off traditional WordPress hosting architecture is worth considering. A WordPress-to-Next.js setup keeps WordPress as a content backend while serving the actual site as static, pre-rendered pages, which removes live database dependency from the front end almost entirely. For a site being redesigned from scratch, going straight from a Figma design to a Next.js build is another way to sidestep this whole class of database-related failure from day one.

Final Thoughts

An “error establishing a database connection” message looks alarming, but it’s rarely fatal — it’s WordPress telling you, in the bluntest way possible, that something between the application and its database needs attention. Most of the time it traces back to credentials, a resource limit, or a corrupted table, and most of the time it’s fixable within minutes once you know where to look.

If you’d rather not diagnose it yourself, or the fix above didn’t bring the site back, reach out by email and it can be looked into directly.