Error establishing a database connection — WordPress fix that actually works

WordPress stores every post, page, user, setting, and comment in a MySQL or MariaDB database. Every page load makes 20 to 200 database queries. When WordPress tries to open that connection and gets refused, it can't render anything, so it shows this bare white page with the error string.

The connection failure is almost always one of four things. Work through them in order — the cheap checks first.

Open wp-config.php via SFTP or your host's File Manager. Find the four lines that define DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST. These have to match exactly what your host set up.

If you recently migrated hosts, restored a backup, or someone rotated the database password — this is your problem 90% of the time. Log into your host control panel (cPanel → MySQL Databases, or MyKinsta → Info, or SiteGround → Site Tools → MySQL), copy the current DB name, username, and host, and update wp-config.php.

The DB_HOST value is not always 'localhost'. Managed hosts like Kinsta, WP Engine, and SiteGround use a specific hostname like 'us-east4-001.mysql.database.yourhost.com'. Copy exactly, no typos, no trailing whitespace.

Save and reload. If the credentials were the problem, the site comes back immediately.

If the credentials are correct and the site still shows the error, the database itself might be unreachable. Two checks.

Host status page: Search "[your host name] status" — hosts publish real-time status. If they're in the middle of a MySQL outage, you're not fixing this from your end. Wait it out.

Database quota: Cheap shared hosts cap the database size (often 1GB) or the number of concurrent connections (often 25). If you hit either, MySQL rejects new connections. Log into your host, check the database usage, and if you're over quota either upgrade the plan or clean up. WP-Optimize or Advanced Database Cleaner can reduce the DB size by clearing spam, revisions, and transients.

If the site was fine an hour ago and just started throwing the error, check for a traffic spike. Legitimate spike (viral post, ad campaign) or malicious (brute force against wp-login.php, XML-RPC flood) both look the same to MySQL: too many connections.

Quick check: look at your host's request log or Cloudflare analytics for the last hour. If wp-login.php or xmlrpc.php has thousands of hits, you're under attack.

Fix: put Cloudflare in front of the site (free plan is fine), enable "Under Attack Mode" for 15 minutes, then set a rate-limit rule on /wp-login.php (10 requests per minute per IP). The connection pressure drops instantly and MySQL recovers.

Rare but real. If a specific page throws the error and others don't, or the error is intermittent, a table might be corrupt.

WordPress has a built-in repair tool. Edit wp-config.php and add 'define("WP_ALLOW_REPAIR", true);' above the '/* That's all, stop editing! */' line. Then visit yoursite.com/wp-admin/maint/repair.php in a browser. Click "Repair Database" (or the safer "Repair and Optimize" if you have time).

When done, remove the define line immediately — leaving that page publicly accessible is a security hole. Save wp-config.php and reload.

If wp-config credentials look right, the host status is green, there's no traffic anomaly, and the repair tool still shows corruption — the fix is probably restoring the database from a backup, and that is not something to guess at with a live store or lead-gen site.

WebCare Studios does emergency database recoveries from $149 including a full point-in-time restore where possible. Median first response is 11 minutes. If the site has been down more than 15 minutes and you'd rather have an engineer just fix it, book the emergency slot below.