How to Fix WordPress Error Establishing a Database Connection

By ErrorFix · Updated October 15, 2026 · 5 min read

What Error establishing a database connection means

WordPress does not store your posts, pages, and settings in files — they live in a MySQL (or MariaDB) database. Every time someone opens a page, WordPress connects to that database using the login details stored in wp-config.php, asks for the content it needs, and builds the page. The "Error establishing a database connection" message appears when that connection attempt fails, so WordPress has nothing to build the page from and shows this plain white screen instead of your site.

The wording is blunt, but the situation is usually less alarming than it looks: this is a connection failure, not data loss. Your content is still sitting in the database untouched in almost every case. The two families of causes are a bad login (wrong database name, username, password, or host in wp-config.php) and a database server problem (MySQL crashed, is being restarted, or is refusing new connections because it is overloaded). One useful clue: if your homepage shows this error but /wp-admin/ shows a message about database tables being unavailable, the fault is corrupted tables rather than the login.

Common causes

• Wrong database credentials in wp-config.php: a typo in DB_NAME, DB_USER, DB_PASSWORD, or DB_HOST — the most common cause, and almost guaranteed if the error appeared right after a host migration, a backup restore, or a database password reset.
• The MySQL or MariaDB server is down: the database service crashed, was restarted, or the host took it offline for maintenance. On shared hosting you cannot restart it yourself; only the host can.
• Corrupted database tables: a failed WordPress or plugin update, or a server crash mid-write, can corrupt tables. WordPress usually flags this itself in /wp-admin/ with a "database may need to be repaired" message.
• Mismatched table prefix or missing privileges: after a migration or restore, the $table_prefix in wp-config.php may not match the actual table names, or the database user may not be assigned to the database with full privileges.
• Server resource limits: a full disk stops MySQL from writing, and a maxed-out connection limit (max_connections) makes the server refuse new connections during traffic spikes — the error appears and disappears with the load.

How to fix Error establishing a database connection — step by step

The whole fix takes about thirty minutes, and step 1 tells you which of the remaining steps you actually need.

1. Check wp-admin to isolate the fault. Open yoursite.com/wp-admin/ in the browser. If the dashboard shows the same database error, the problem is the database login or the database server itself — continue with steps 2 through 4. If wp-admin instead shows "One or more database tables are unavailable. The database may need to be repaired," your tables are corrupted and you can skip straight to step 5. This one check tells you which fix to pursue first, so do not skip it.
2. Verify the database credentials in wp-config.php. Open wp-config.php in cPanel File Manager or an FTP client and compare the four values with your hosting panel's MySQL Databases page: DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST. Re-copy the password from the panel rather than typing it from memory — passwords changed during a migration or a security reset are the classic culprit. Check DB_HOST carefully too: it is localhost on many hosts, but managed and cloud hosts often use a separate database hostname, and a migration silently breaks this value. Correct anything that differs, save the file, and reload the site.
3. Confirm the database server is actually running. Log in to your hosting panel and look for the services or server status section — a stopped MySQL or MariaDB service needs a restart from the host's side. A quicker test is phpMyAdmin: open it from the hosting panel, and if it cannot connect either, the database server is down and no WordPress setting will fix it — this is a host problem, not a WordPress problem. If other sites on the same server show the same error, the whole database server is affected. Open a support ticket and ask the host to check and restart the MySQL service.
4. Wait out a transient overload, then add caching. On shared hosting, the error sometimes appears during traffic spikes or server maintenance and clears on its own within 10 to 15 minutes — the server temporarily refuses new database connections because it hit its max_connections limit. Wait, then retest before changing anything. If the error keeps coming and going on a schedule, every page load is hammering the database: install a caching plugin so most visits never touch MySQL at all, and talk to your host about a plan with a higher connection limit if it keeps recurring.
5. Repair corrupted database tables. If wp-admin reported that tables are unavailable, open wp-config.php and add this line above the "That's all, stop editing!" comment: define('WP_ALLOW_REPAIR', true);. Then visit yoursite.com/wp-admin/maint/repair.php and click Repair Database (Repair and Optimize also works). Wait for every table to report OK, then reload your site. Important: remove the WP_ALLOW_REPAIR line from wp-config.php immediately afterward — the repair page is reachable by anyone who knows the address while that line is present, and you do not want strangers running database repairs.
6. Fix the table prefix and database user privileges after a migration. In phpMyAdmin, check whether your tables start with the same prefix that wp-config.php sets in $table_prefix — for example, the config says wp_ but the actual tables are wp_ab12_. If they differ, update $table_prefix in wp-config.php to match the real tables. Then, in the hosting panel under MySQL Databases, confirm the database user is assigned to the database with ALL PRIVILEGES checked. A user without privileges or a mismatched prefix produces exactly this error right after a migration or restore, even when the password is correct.

Did this fix it? Quick checklist

• DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST in wp-config.php match the hosting panel's MySQL settings exactly
• phpMyAdmin connects successfully, proving the MySQL server is running
• The repair page at /wp-admin/maint/repair.php shows every table as OK
• $table_prefix in wp-config.php matches the actual table names in phpMyAdmin

If the checklist is clean and the error persists, the fault is deeper in the server: ask your host to check the MySQL error log for crashes and whether the server is hitting its max_connections limit. As a last resort, restore the site from a recent backup — hosts like Bluehost, SiteGround, and Hostinger keep automatic daily backups, and a full restore (files plus database) replaces anything the repair tool could not save. And once the site is back, install a backup plugin and keep your own copies off the server, so the next database hiccup is a five-minute restore instead of a scramble.