The error establishing a database connection in WordPress usually means the credentials in your wp-config.php file no longer match your database, most often after a migration or host change. The second most common cause is a database server that is down or overloaded. Diagnose which one you have before changing anything, then apply the matching fix.
We fix this error on client sites often enough that we have learned the fastest route is not to start editing files. It is to spend two minutes working out what actually broke. Most guides hand you a list of eight fixes and let you try them at random. That approach can turn a five-minute credential fix into an afternoon, and a couple of those fixes carry real data-loss and security risk if you run them blind. This guide diagnoses first, then fixes.
What causes the error establishing a database connection?
This error appears when the PHP-to-MySQL handshake fails completely. WordPress uses PHP to run its code and MySQL to store your content, and the connection details live in wp-config.php. When WordPress cannot connect, it cannot fetch anything, so the whole site goes down at once: front end, wp-admin, REST API, all of it. The failure sits at the connection level, not the content level, which is why a single broken value takes the entire site offline.
Six root causes account for almost every case:
- Incorrect database credentials in wp-config.php (DB_NAME, DB_USER, DB_PASSWORD, or DB_HOST)
- A database server that is down, unresponsive, or overloaded
- Corrupted database tables
- Corrupted WordPress core files
- A plugin or theme conflict, usually right after an update
- Insufficient privileges for the database user
The point of the next section is to tell these apart. Each has a different fix, and running the wrong fix wastes time or, worse, creates a new problem.
How do you diagnose the real cause before changing anything?
Spend two minutes narrowing the cause before you touch a file. Three quick checks tell you most of what you need, and they cost nothing. Skipping this step is the single most common reason a simple fix turns into hours of guessing.
Check the front end against wp-admin.
Load your homepage, then load yoursite.com/wp-admin. If both show the standard error, you are likely looking at wrong credentials or a downed server. If the front end shows the standard error but wp-admin shows “One or more database tables are unavailable. The database may need to be repaired,” that is a different problem: your database is reachable but a table is corrupted. That case skips the credential fix entirely and goes straight to the repair tool in the corruption section below.
Ask what changed right before it broke.
The trigger usually names the cause. If the error started right after you migrated to a new host, suspect credentials first, because they rarely carry over. If it started right after a plugin or theme update, suspect a conflict. If it appears only during traffic spikes and clears on its own, suspect a server hitting its connection limit rather than anything in your files.
Check whether the server itself is reachable.
Log into your hosting panel and open phpMyAdmin. If you can see and browse your database tables, the server is running and the problem is on your side (credentials, corruption, or files). If phpMyAdmin will not connect either, the database server is likely down, and that is your host’s responsibility, not yours.
One rule before any fix that follows: back up your files and database first. Every step below changes something load-bearing, and a recent backup is what lets you undo a mistake instead of living with it. If you cannot reach wp-admin to run a backup plugin, export the database from phpMyAdmin and download your files over FTP.
How to fix incorrect database credentials in wp-config.php
Fixing credentials means matching four values in wp-config.php to what your database actually uses. This is the most common cause, so start here unless your diagnosis pointed clearly elsewhere. The wp-config.php file sits in your site’s root directory, the folder that also contains wp-admin, wp-content, and wp-includes. Open it with your host’s file manager or over FTP.
Inside, find these four lines:
- DB_NAME: the database name
- DB_USER: the database username
- DB_PASSWORD: that user’s password
- DB_HOST: the database server address
One wrong character in any of them breaks the connection. Compare each value against the real database details in your hosting panel, and correct any mismatch. After a migration this is almost always the problem, because the new host assigns a new database name, user, and sometimes a different host value.
Watch DB_HOST specifically. Many guides assume it is always “localhost,” but plenty of hosts use a specific server name or an IP address instead. If your other three values are correct and the error persists, a wrong DB_HOST is the usual culprit, and your host’s documentation lists the correct value.
How do you find the correct database details?
Read them from your hosting control panel. In cPanel, open MySQL Databases to see the exact database name and its assigned users, then confirm the user has privileges on that database. If you are unsure of the password, reset it in the same panel and paste the new value into wp-config.php. The goal is an exact match on all four values, with no stray spaces or typos. Save the file, upload it back if you edited it locally, and reload your site.
How to repair a corrupted WordPress database
If your diagnosis showed the “tables are unavailable” message in wp-admin, your database needs repair, not new credentials. WordPress ships with a built-in repair tool that you enable with one line. Open wp-config.php and add this line just above the “That’s all, stop editing” comment:
define(‘WP_ALLOW_REPAIR’, true);
Save the file, then visit yoursite.com/wp-admin/maint/repair.php in your browser. You will see two buttons: Repair Database, and Repair and Optimize Database. Repair alone is faster and usually enough. Repair and Optimize also cleans up the tables but takes longer, so use it only if the plain repair does not resolve the error.
Here is the part most guides bury, and it matters. The repair page is accessible to anyone with no login required, so leaving it enabled is a live security hole. The moment the repair finishes, go back into wp-config.php, delete the WP_ALLOW_REPAIR line you added, and save the file again. Do not skip this. An open repair endpoint is exactly the kind of thing automated scanners look for.
Is your database server down or overloaded?
If phpMyAdmin would not connect during your diagnosis, the database server itself is the problem, and that is often out of your hands. On shared hosting, many sites share the same database resources, so a neighbor’s traffic spike or your own can push the server past its limits and drop connections. When that happens, the error appears, then clears on its own once load falls.
To confirm, try opening phpMyAdmin again after a few minutes. If it is intermittently reachable, you are almost certainly hitting a resource ceiling rather than a broken setting. Contact your host, tell them when the error started and that you suspect the database server, and ask them to check whether it is down, overloaded, or hitting a max-connections limit. A downed or overloaded server is genuinely their job to fix, and no amount of file editing on your end will solve it.
How to rule out a plugin or theme conflict
A plugin or theme with faulty code can trigger this error, usually right after you install or update one. To test plugins when you still have wp-admin access, deactivate them all, then reload the site. If the error clears, reactivate them one at a time until it returns, and you have found the offender.
If wp-admin is locked, you can still deactivate everything over FTP. Rename the wp-content/plugins folder to plugins_old, then reload your site. WordPress cannot find the plugins, so it deactivates them all at once. If that fixes the error, rename the folder back to plugins and the individual plugin subfolders will still be deactivated, letting you re-enable them one by one to isolate the culprit. To test a theme the same way, switch the active theme through the database in phpMyAdmin when you cannot reach the dashboard.
How to replace corrupted WordPress core files
Corrupted core files can cause this error after a failed FTP transfer, a security compromise, or a host-side problem. The fix is to replace the core files with fresh copies, and it is safe as long as you touch only the right ones. Download a clean copy of WordPress from wordpress.org, then upload everything except the wp-content folder to your site’s root over FTP, telling the client to overwrite existing files.
The honest tradeoff here: replacing core files is low risk for your content, since you leave wp-content (themes, plugins, uploads) untouched, but it can overwrite custom edits you made to root-level files like .htaccess or a manually customized wp-config.php. If you added custom rules to those files, save copies before you overwrite, then reapply your changes afterward. This is exactly why the backup step earlier is not optional.
What if the error keeps coming back?
A recurring database connection error points to a root cause you have not fixed yet, not a one-time glitch. If the error returns under traffic and clears when things quiet down, you are almost certainly hitting your host’s connection or resource limits, and the real fix is more resources or better hosting, not another round of file edits. Shared plans are the usual setting for this pattern.
If it recurs without a traffic pattern, look for a plugin that repeatedly corrupts tables, a database that is genuinely damaged beyond a quick repair, or a host with an unstable database server. At this point the useful question changes from “how do I clear the error today” to “what keeps breaking.” That is often where a developer earns their fee, because chasing a recurring, intermittent failure across plugins, hosting limits, and database health is slow, careful work, and guessing at it can make things worse.
When should you call a developer or your host?
Call your host when phpMyAdmin will not connect, when other sites on the server are also down, or when you suspect a server-level problem, because those are theirs to fix. Call a developer when the error recurs, when a fix risks data loss you are not comfortable with, or when you have worked through credentials, repair, plugins, and core files without a stable result.
There is no shame in stopping. This error takes your whole site offline, which means every hour it stays broken costs you visitors and trust, and a wrong move during troubleshooting can turn a quick fix into lost data. If the site is business-critical and you are guessing, a professional is almost always cheaper than a mistake. Knowing when to hand it off is a skill, not a failure.
Need this fixed properly, without the guesswork?
Most database connection errors come down to four values in wp-config.php, a corrupted table, or a server that needs your host’s attention. Diagnose first, apply the matching fix, and keep a backup within reach, and you can restore a downed site in minutes rather than hours. The steps in this guide cover every common cause, from a botched migration to a plugin that corrupts tables under load.
Some sites, though, are too important to experiment on, and some errors keep coming back no matter how many fixes you try. That is the work we do best. Survyc is an AI-first digital agency that handles WordPress fixes, migrations, and ongoing maintenance for agencies and the clients they stand behind. We work white label as part of your team, so your client sees their site fixed and you get the credit. If your site is down, or you want a partner who handles this so you never have to, contact us at info@survyc.com and tell us what you need.
Frequently asked questions
Can a plugin cause the error establishing a database connection?
Yes. A plugin with faulty code, most often one you just installed or updated, can trigger this error or corrupt your database. Test by deactivating all plugins, either from wp-admin or by renaming the wp-content/plugins folder to plugins_old over FTP. If the error clears, reactivate plugins one at a time until it returns to find the specific one at fault.
Will I lose data fixing this error?
Usually no, if you back up first and follow the steps carefully. Correcting wp-config.php credentials and running the database repair tool do not delete content. The real risk is replacing core files, which can overwrite custom edits to root files like .htaccess or wp-config.php. A full backup of files and database before you start is what lets you undo any mistake without losing data.
Why does this error happen after migrating to a new host?
Because database credentials rarely carry over. A new host assigns a new database name, username, and sometimes a different DB_HOST value, so the old values in your wp-config.php no longer match. This is the single most common cause after a migration. Update DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST to match the new host’s database details, and the site typically reconnects.
How do I fix the error without cPanel or wp-admin access?
Use FTP. Connect with an FTP client, open wp-config.php in your site’s root to check and correct the database credentials, and rename the wp-content/plugins folder to test for plugin conflicts. You can also replace core files over FTP. If you cannot reach the database at all through any method, the server is likely down and your host needs to resolve it.
Is this error my fault or my hosting provider’s?
It depends on whether the database server is reachable. Open phpMyAdmin from your hosting panel. If you can browse your tables, the server is fine and the cause is on your side: credentials, corruption, or files. If phpMyAdmin also fails to connect, or other sites on the server are down, the database server itself is likely the problem, and that is your host’s responsibility to fix.
How long does it take to fix this error?
A credential fix in wp-config.php often takes five minutes once you have the correct database details. A database repair adds a few minutes. Server-level problems depend on your host’s response time. Recurring or intermittent errors take the longest, because the work is a diagnosis rather than a single edit. Diagnosing the cause first is what keeps most cases short.
