How to Fix Error Establishing a Database Connection WordPress

Your site was fine an hour ago. Now every URL returns one cold line of text: Error establishing a database connection. No dashboard, no posts, no images — just a blank white page and that sentence. If you've just switched hosts, changed a password, or watched a traffic spike roll in, this is one of the fastest ways a WordPress site goes dark. The reassuring part: most cases are fixable in minutes once you know how to fix error establishing a database connection WordPress puts in front of you.

This guide ranks every real cause by how often it actually happens — drawing on what we see daily across the sites we run at Hostaccent — then gives you the exact files, lines, and commands to check each one, calmly, in order.

Quick Answer: WordPress shows "Error establishing a database connection" when it can't reach its MySQL database. Nine times out of ten the cause is wrong credentials in wp-config.php (especially right after a migration) or a database server that's down or out of connections. Open wp-config.php, confirm the database name, user, password, and host, then verify MySQL is actually running.

What This Error Actually Means

WordPress keeps almost everything — your posts, pages, users, settings, comments — inside a MySQL or MariaDB database. The files on disk (your theme, plugins, PHP) are only half the site. Every time someone loads a page, PHP has to open a live connection to that database and pull the content out.

To open that connection, PHP reads four values from a single file, wp-config.php:

• The database name
• The database user
• That user's password
• The database host (usually localhost)

If any one of those four is wrong, or the database server isn't answering, the connection fails — and WordPress has no graceful fallback. It just prints the error and stops. So this is rarely a "WordPress is broken" problem. It's almost always a "WordPress can't reach its data" problem, which is a much smaller thing to fix.

Insider Insight: This error and a 500 Internal Server Error look similar (both white pages), but they're different beasts. A 500 is usually PHP or .htaccess; the database error is specifically the connection between PHP and MySQL. Knowing which one you're staring at saves you ten minutes of looking in the wrong place.

The Real Causes, Ranked by How Often We See Them

Forget the generic "ten reasons" lists. In the tickets our support team handles, the order of frequency is remarkably consistent. Here's roughly how it breaks down on our own servers, most common first:

1. Wrong or changed credentials — by a wide margin the number one cause, and it spikes right after a migration. A wp-config database error is almost a rite of passage when you move hosts.
2. The database server is overloaded or out of connections — the classic "too many connections" WordPress failure, common on busy shared accounts.
3. Corrupted database tables — usually after an unexpected reboot, a crashed plugin write, or a disk that filled up.
4. MySQL/MariaDB crashed or got killed — often an out-of-memory event on a small server.
5. A wrong DB_HOST value — localhost versus 127.0.0.1 versus a remote host string.

Work down this list in order and you'll resolve the overwhelming majority of incidents before you ever reach the bottom.

How to Fix Error Establishing a Database Connection in WordPress

This is the part you came for. Each step is ordered most-likely-first, so start at the top and stop as soon as your site loads.

Step 1: Verify Your Credentials in wp-config.php

Open wp-config.php in your site's root folder (via SFTP, SSH, or your host's file manager) and find these four lines:

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

When we migrate customer sites, we repeatedly see the same three slips here:

• The database name picked up a prefix. Many panels create databases as cpanelusername_dbname, so a name that worked on the old host is now wrong.
• The user is different. The old database user rarely transfers; the new host issued a new one with a new password.
• A typo or a stray space inside the quotes — invisible, and enough to break the connection.

Fix any mismatch so all four values match what your current host's control panel or database tool shows. Save the file and reload your site. If the credentials were the problem — and they usually are — you're done. The official WordPress.org database documentation is worth a bookmark for what each value controls.

Pro Tip: After a migration, check DB_HOST before you touch anything else. Some stacks expect localhost; others only connect through 127.0.0.1 or a dedicated host like mysql.yoursite.com. If your credentials look perfect but the connection still fails, swapping localhost for 127.0.0.1 is the single highest-payoff one-character change you can make.

Step 2: Test the Credentials Directly

Don't assume the credentials are right — prove it. Drop a tiny test file named db-test.php in your site root:

phpCopy
<?php
$link = mysqli_connect('localhost', 'your_database_user', 'your_database_password', 'your_database_name');
if (!$link) {
    die('Connection failed: ' . mysqli_connect_error());
}
echo 'Connected successfully';

Visit yoursite.com/db-test.php. "Connected successfully" means your credentials are fine and the fault lies elsewhere (jump to Step 3). An "Access denied" message means the username or password is wrong; "Unknown database" means the name is wrong. The php.net mysqli connection manual explains each error string. Delete the test file the moment you're finished — never leave credentials sitting in a public file.

Step 3: Check Whether MySQL Is Actually Running

If the credentials test passes but WordPress still fails, the database service itself is probably down or unreachable.

On a VPS or server you control, check and restart it:

bashCopy
sudo systemctl status mariadb
sudo systemctl restart mariadb

On our own Nginx → Apache + NVMe stack, the usual reason MySQL stops answering is a memory squeeze — a small server runs out of RAM, the kernel kills the database process to stay alive, and every site on it throws this exact error until the service comes back. If you're on shared hosting and can't run those commands, this is the moment to open a support ticket: only the host can restart the database server. A genuinely good support team will tell you straight whether it was your site or theirs.

Step 4: Rule Out a Host-Side Outage

Before you spend another hour inside your own files, confirm the problem is actually yours. If the database server is overloaded or undergoing maintenance, no amount of wp-config editing will help.

Check three things fast:

• Your host's status page or X/Twitter account — a platform-wide incident shows up here first.
• A second site on the same account — if every site you host fails at once, it's the server, not your WordPress install.
• Your control panel — if you can't even reach phpMyAdmin or the panel itself feels frozen, the database layer is struggling host-side.

When all your sites fail together, stop debugging and contact support with the timestamp. Across the sites we host, the single biggest time-waster is an owner rewriting perfect credentials during an outage that was never their fault.

How to Repair Corrupted WordPress Database Tables

Sometimes the connection succeeds but specific tables are damaged — you'll often see a hint like "One or more database tables are unavailable." WordPress has a built-in repair tool for exactly this.

Add this line to wp-config.php, just above the /* That's all, stop editing! */ comment:

phpCopy
define( 'WP_ALLOW_REPAIR', true );

Then visit yoursite.com/wp-admin/maint/repair.php (no login needed) and click Repair Database. When it finishes, remove that line immediately — leaving it live is a security hole, since anyone could trigger a repair.

Prefer doing it by hand? In phpMyAdmin, open your database, tick the affected tables (or check the box for all), and choose Repair table from the "With selected" dropdown. From the command line it's one line:

bashCopy
mysqlcheck --repair --databases your_database_name -u root -p

Pro Tip: The wp_options table is the usual culprit when a site half-loads or the admin area behaves strangely. A bloated, corrupted wp_options — often stuffed with leftover transients from removed plugins — repairs cleanly with REPAIR TABLE wp_options; and frequently fixes a database connection error that the credential check couldn't explain. If your site has felt sluggish too, our slow WordPress site guide covers trimming that table properly.

Why "Too Many Connections" Hits Shared Hosting Hardest

Here's the part nobody warns first-time site owners about. A MySQL server only accepts a fixed number of simultaneous connections — controlled by max_connections, and per-user by max_user_connections. Hit the ceiling and the very next request gets "Error establishing a database connection," even though your credentials are perfect and nothing is corrupted.

On a crowded shared server, that ceiling is shared. Dozens of accounts can draw from the same pool, and per-user caps are often set low — commonly in the 25–50 range — to keep one site from starving the rest. So a neighbour's traffic spike, runaway plugin, or backup job can exhaust the connections and take your site down with it. You did nothing wrong; you just shared a wall with a noisy tenant. The MySQL documentation on "Too many connections" explains the limit in detail.

This is exactly where isolation changes everything, and it's why Hostaccent runs each account with its own PHP-FPM pool and ring-fenced database resources rather than one shared free-for-all. When connections are allocated per user, another customer's bad afternoon can't drain your limit. Sites that constantly brush against connection caps almost always need this kind of separation — the same logic behind moving high-demand stores onto hosting built for high-traffic WordPress.

If your database error tends to appear precisely when traffic climbs, that's the connection ceiling talking — not a credential problem. A 504 timeout under load is its close cousin; our 504 Gateway Timeout fix walks through that overlap.

How to Stop It From Happening Again

Fixing the incident is step one. Making sure it doesn't recur — as of June 2026, this is what genuinely moves the needle:

• Keep credentials documented. Before any migration, write down the new database name, user, password, and host. Most repeat incidents are just a forgotten wp-config database error from the last move.
• Add object caching. A persistent object cache (Redis or Memcached) cuts the number of database queries per page hard, which keeps you well under any connection ceiling.
• Monitor your database. Uptime and resource monitoring tells you the server is straining before visitors see the error, not after.
• Right-size your hosting. If you keep hitting "too many connections" WordPress errors, you've outgrown a shared pool. Isolated database resources are the durable fix — our VPS for WordPress buyer's guide lays out when that jump is worth it.

Insider Insight: A frequent misconfiguration we see is a perfectly healthy site sharing a database server with a forgotten staging copy that's still running cron jobs and eating connections. Delete or pause old staging installs — they're invisible until they take production down.

Where to Run WordPress When This Rarely Happens

Most of this article is host-agnostic — these steps work wherever your site lives. But the recurring version of this error, the "too many connections" kind that strikes under load, is fundamentally a resource problem, and resource problems are solved by isolation.

Hostaccent VPS plans (from $22.00/mo for the Professional tier) give each site its own PHP-FPM pools, isolated database resources, and NVMe SSD storage behind a Cloudflare and Nginx → Apache stack — so a neighbour's spike can't drain your connections. As a UK-registered company with a Bangladesh branch and human support, we'd rather help you prevent this error than reset it at 2 a.m. If you've fixed it more than once this year, that's usually the signal it's time to move off a shared pool.

Frequently Asked Questions

How do I fix error establishing a database connection in WordPress?

Open wp-config.php and confirm the database name, user, password, and host are correct — this fixes most cases, especially after a migration. If credentials check out, test the connection with a small script, then verify the MySQL service is running and hasn't hit its connection limit.

Why does this error appear right after migrating my site?

Migrations almost always change your database credentials. The new host issues a new database name (often with a prefix), a new user, and a new password, but your old wp-config.php still holds the previous values. Updating those four lines to match the new host resolves the migration database error in most cases.

Can a corrupted database cause the connection error?

Yes. If the connection succeeds but tables are damaged, you'll often see a note about unavailable tables. Add define('WP_ALLOW_REPAIR', true); to wp-config.php, visit /wp-admin/maint/repair.php, run the repair, then remove that line. You can also repair the WordPress database manually in phpMyAdmin.

What does "too many connections" mean in WordPress?

It means the MySQL server has hit its maximum simultaneous connections, set by max_connections and max_user_connections. On shared hosting these limits are shared across accounts, so a neighbour's traffic can exhaust them and trigger the error on your site even when nothing is wrong with your configuration.

Should DB_HOST be localhost or 127.0.0.1?

It depends on your stack. Most setups use localhost, but some connect only through 127.0.0.1 or a named host like mysql.yoursite.com. If your credentials are correct but the connection still fails, switching between localhost and 127.0.0.1 is a quick, common fix worth trying.

Does this error mean I lost my website data?

Almost never. The error is about reaching the database, not losing it. Your content is still stored; WordPress simply can't connect to retrieve it. On isolated hosting like a Hostaccent VPS with regular backups, even a corrupted-table scenario is recoverable — fix the connection or restore the table, and your data returns intact.

How long does it take to fix this error?

If it's wrong credentials — the most common case — you can be back online in two to five minutes once you find the right values. A table repair takes a few minutes more. A host-side outage is out of your hands and depends on your provider's response time, which is one more reason support quality matters when you choose where to host.

Reviewed and updated by The Hostaccent Team — a UK-registered host with a Bangladesh branch, serving customers worldwide — as of June 2026.