Fix 'Error Establishing a Database Connection' (2026)

Last updated: October 9, 2026.

You open your site and instead of your homepage you get a stark white page: “Error establishing a database connection.” Your stomach drops — and then you try wp-admin and get the same thing. Before you do anything, take a breath and read two facts that change how you approach this: first, this error is about reaching your database, not losing it. Your content is almost certainly still sitting there intact. Second, in the majority of cases this is a five-minute fix — wrong credentials in wp-config.php — and the fastest way to find your fix is to diagnose in the right order instead of trying random solutions from a forum thread.

This guide walks you through the error establishing a database connection WordPress problem in order of likelihood: a 60-second diagnosis, then each fix from most to least common. Every step is verified against official WordPress documentation and current hosting guides.

Table of Contents

The 60-Second Diagnosis: What Kind of Outage Is This?

Don’t touch any files yet. Answer these questions first — they tell you which fix to jump to:

Did it appear right after a migration, domain move, or host change? → Your database credentials almost certainly changed. Jump to Fix 1.
Does wp-admin show “One or more database tables are unavailable”? → That’s a different message with a different cause: corrupted tables. Jump to Fix 5.
Does the error come and go, worse during traffic spikes? → You’re likely hitting a connection limit. Jump to Fix 6.
Is it constant, and nothing on your side changed? → The database server itself may be down. Jump to Fix 4.
Nothing changed and it’s constant, but other sites on the same host work fine? → Credentials or host configuration. Start with Fix 1.

Also check: do you run any other site on the same hosting account or server? If that site is down too, the problem is on your host’s side, not in your WordPress files — and no amount of editing wp-config.php will fix it.

Fix 1: Check Your Database Credentials in wp-config.php

This is the cause in the large majority of cases — especially after migrations, where the new host issues a new database name, user, and password while your old wp-config.php still holds the previous values.

Open wp-config.php in your site’s root directory (via your host’s File Manager or SFTP) and find these four lines:

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

Now log into your hosting control panel, open the MySQL Databases section, and compare each value, one by one:

DB_NAME — the database must actually exist. Many hosts add a prefix to database and user names (e.g. accountname_wp482), so copy the exact name from the panel rather than typing it from memory.
DB_USER — the user must exist and be assigned to the database with all privileges. A user that exists but was never added to the database will fail with this exact error.
DB_PASSWORD — if you don’t know the current password, reset it in your hosting panel and paste the new one into wp-config.php. Don’t guess.
DB_HOST — covered in detail in Fix 2 below.

While you’re in wp-config.php, also check the table prefix line:

$table_prefix = 'wp_';

If you migrated a site, the prefix in the file must match the actual table names in the database (check via phpMyAdmin). A mismatch here — for example the file says wp_ but the tables are named wp2_ — breaks the connection just as thoroughly as wrong credentials.

Save the file, reload your site. If it loads, you’re done — and you’ve just fixed the most common WordPress database error there is.

Fix 2: Check Your DB_HOST Value

If the credentials check out but the wordpress database connection error persists, the hostname is the next suspect. Most setups use localhost, but some hosts require 127.0.0.1, a named host like mysql.yourhost.com, or a host with a custom port:

define( 'DB_HOST', 'localhost:3307' );

Two practical notes here:

localhost and 127.0.0.1 take different connection paths under the hood (socket vs TCP). If your credentials are definitely correct and the connection still fails, switching between the two is a quick, legitimate fix worth trying.
Some hosts require you to register the MySQL hostname in the control panel before it works, and it can take a little while to become active. If your host gave you a custom DB host, confirm with their documentation or support that it’s the right one.

Fix 3: Test the Connection Yourself With a Throwaway Script

At this point you want to know: is it WordPress, or is it the database? A tiny standalone script answers that in seconds. Create a file called db-test.php in your WordPress root with this content (fill in your real values from wp-config.php):

<?php
$connection = new mysqli( 'localhost', 'database_user', 'database_password', 'database_name' );
if ( $connection->connect_error ) {
    die( 'Connection failed: ' . $connection->connect_error );
}
echo 'Database connection successful';

Open it in your browser at yoursite.com/db-test.php:

It fails → the problem is at the database level: wrong credentials or a down server. The exact error message it prints tells you which.
It succeeds → the database is reachable and your credentials work, so the problem is inside WordPress itself: corrupted tables (Fix 5) or damaged core files.

Delete this file immediately after testing. It contains your database password in plain text, and leaving it on the server is an open invitation.

Fix 4: Check Whether the Database Server Is Running

If your credentials are correct and your throwaway script still fails, the database server itself is the problem. How you check depends on your hosting:

On shared hosting: you can’t restart the server yourself. Check your host’s status page for ongoing maintenance, and check whether your other sites on the same account are down. Then contact support and ask directly: is the MySQL/MariaDB server up, and are other accounts on the same server affected? A straight answer to that question saves you hours of pointless file editing.

On a VPS: you can check it yourself over SSH:

# Is the database service running?
sudo systemctl status mysql --no-pager || sudo systemctl status mariadb --no-pager

# Quick connectivity test (prompts for password if needed)
mysqladmin ping -h 127.0.0.1

If the service is stopped, restart it with sudo systemctl restart mysql (or mariadb) — then investigate why it stopped, because a database that dies once will die again. Two common culprits on small VPS plans:

Out of memory. MySQL is often the first process the kernel kills when RAM runs out. Check dmesg | grep -i oom and consider adding swap or upgrading the plan.
Full disk. A database server cannot write to a full disk and will refuse connections. Run df -h — if you’re at 100%, clear old backups, logs, or cache files before restarting.

Fix 5: Repair a Corrupted Database

If wp-admin shows “One or more database tables are unavailable” — or your throwaway script connects fine but WordPress still fails — some of your tables are damaged. WordPress ships with a built-in repair tool. To enable it, 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 in your browser. You’ll get two buttons: Repair Database and Repair and Optimize Database. Pick “Repair and Optimize” — it fixes damage and cleans up overhead in one pass. WordPress will list each table and what it did.

Security warning, and it’s a serious one: while that constant is enabled, anyone on the internet can access the repair page without logging in — that’s by design, since a corrupted database often means you can’t log in. Remove the line from wp-config.php the moment the repair finishes. Leaving it enabled is a documented security risk in the official WordPress docs.

Two alternatives if the built-in tool doesn’t cut it:

phpMyAdmin: select your database, tick all tables, choose Repair table from the dropdown.
WP-CLI (SSH access required): wp db repair repairs tables directly from the command line, and wp db check tells you which tables are damaged first.

Fix 6: The Intermittent One — “Too Many Connections”

If the error establishing a database connection appears and disappears — fine at night, broken at peak hours — you’re probably exhausting the database’s connection limit. MySQL has a max_connections setting (and hosts often add a per-user max_user_connections cap). Every uncached WordPress page load opens one or more database connections; when the pool is full, new visitors get the error.

This is especially common on shared hosting, where the connection pool is shared across accounts — a neighbour’s traffic spike can trigger the error on your site even when nothing is wrong with your configuration. What you can actually do:

Add page caching. A caching plugin turns most visits into static HTML that never touches the database. This is the single biggest lever you have.
Add an object cache (Redis or Memcached) so repeated queries are served from memory instead of opening work against MySQL.
Audit heavy plugins. Backup, security-scan, and statistics plugins that run on every page load are classic connection hogs. Move scheduled scans to off-peak cron jobs.
Talk to your host. Ask what your connection limits are and whether they’ve been hit. If the answer is “yes, regularly,” the honest fix is a plan with dedicated resources — no amount of tuning overcomes a pool that’s simply too small.

What to Tell Your Hosting Support (So You Get a Fast Answer)

If you reach the point of contacting support, don’t open with “my site is down.” Open with this and you’ll skip three rounds of back-and-forth:

When the error started, and whether it’s constant or intermittent.
Whether wp-admin is affected too, or only the frontend.
Anything that changed recently: migration, new plugin, traffic spike.
What you’ve already verified: credentials match the panel, DB_HOST value, result of a direct connection test.
The exact error message your connection test returned, if any.

Prevent It From Happening Again

Once you’re back online, a few habits make this a once-a-year event instead of a recurring nightmare:

Automated offsite backups. Even though this error rarely means data loss, the day you need a restore is the day you’ll wish you’d set it up. (We have a full guide: how to set up automated VPS backups.)
Uptime monitoring. A free monitor that pings your site every few minutes tells you about the next outage before your visitors do.
Never leave repair mode or test scripts on the server. Make “remove the line, delete the file” part of the fix, not an afterthought.
Test migrations on staging first. Most credential-drift outages happen because a migration was done live, in a hurry, at midnight.
Keep the plugin count lean. Every plugin is a potential source of runaway queries and connection exhaustion.

How to Fix “Error Establishing a Database Connection” in WordPress (2026)