Fixing the “Error Establishing a Database Connection” Fast

When a visitor sees “Error establishing a database connection,” it means PHP ran fine but WordPress could not reach MySQL. In the vast majority of cases the cause is one of three things: wrong credentials in wp-config.php, a stopped or overloaded MySQL service, or corrupted tables. Checked in the right order, most sites are back online in under ten minutes.

The trick is resisting the urge to start editing files immediately. A two-minute triage tells you whether the problem is on your side or your host’s, and that single answer saves you from changing things that were never broken.

What the Error Actually Means

WordPress stores every post, option, user and comment in a MySQL or MariaDB database. On each page load it opens a connection using four values from wp-config.php: database name, username, password and host. If any part of that handshake fails, WordPress stops and prints the error instead of your site.

That matters for diagnosis, because the message is generic by design. The same screen appears whether the password changed, the database server crashed, or the connection limit was hit during a traffic spike. Your job is to narrow those down fast.

The First Two Minutes: Triage Before You Touch Files

Run these three checks before editing anything:

• Check wp-admin separately. If the front end is broken but /wp-admin shows “One or more database tables are unavailable,” you likely have table corruption rather than a credentials problem.
• Check your host’s status page. A platform-wide database incident is not something you can fix from wp-config.php. Our own live platform status page is the first place our customers look.
• Ask what changed in the last hour. A plugin update, a migration, a password rotation or a sudden traffic surge explains the error far more often than random failure does.

If other sites on the same server are also down, stop troubleshooting WordPress and open a ticket. If only one site is affected, the cause is almost certainly local to that install.

Check the Database Credentials in wp-config.php

Open wp-config.php in the site root using SFTP or your file manager, and read the four defined constants near the top: DB_NAME, DB_USER, DB_PASSWORD and DB_HOST. Compare each value against what your control panel shows under MySQL databases. A single stale password here breaks the whole site.

DB_HOST is the sneaky one. On most servers it should be localhost, but several managed and shared platforms use an internal hostname or a value like 127.0.0.1:3306 instead. GoDaddy and a few other shared hosts historically used dedicated hostnames, so copying a wp-config.php from an old host after a move is a classic trigger for this error.

If you are unsure whether the credentials work at all, create a small PHP test file in the site root:

• Add a short script using mysqli_connect() with the same four values.
• Load it in a browser and read the result.
• A successful connection points to a WordPress-level issue; a failure confirms the credentials or the database server.
• Delete the file immediately afterward so the credentials are not left exposed.

The official WordPress documentation on editing wp-config.php lists every constant and its accepted format if you want to verify syntax.

We cover this topic in more depth in Fixing Mixed Content Warnings After Forcing SSL/HTTPS.

When MySQL Is Down or Out of Connections

If credentials check out, the database service itself is the next suspect. On a VPS or dedicated server, SSH in and run systemctl status mysql (or mariadb). A service that stopped usually left a reason in /var/log/mysql/error.log, and the two most common reasons are the server running out of RAM and the disk filling up.

Disk space deserves a quick df -h every time. MySQL cannot write to its tables or temp files on a full volume, and it will refuse connections rather than corrupt data. Clearing old backups or log files often restores service within seconds of a restart.

The other frequent cause is hitting max_connections. Each visitor, cron job and background query holds a connection, and once the limit is reached new requests are rejected with “Too many connections.” MySQL’s reference manual explains how the connection limit behaves under load, and on busy sites raising it without adding memory just moves the failure point.

Repairing Corrupted Tables

Corruption shows up after hard crashes, interrupted migrations or unclean shutdowns. WordPress ships with a built-in repair tool that you enable by adding one line to wp-config.php:

• Add define(‘WP_ALLOW_REPAIR’, true); above the “That’s all, stop editing” comment.
• Visit yoursite.com/wp-admin/maint/repair.php and choose “Repair Database.”
• Remove that line as soon as you are done, because the page requires no login.

If the repair tool cannot load, use phpMyAdmin instead: select all tables, then choose Repair table from the dropdown. For InnoDB tables, which most modern installs use, a restore from backup is usually faster and safer than forcing an innodb_force_recovery start.

Localhost, XAMPP and Local Development

The same error on a local XAMPP or MAMP install almost always means the MySQL module simply isn’t running. Open the control panel, start MySQL, and confirm the port is 3306 and not taken by another service such as Skype or an older MySQL instance.

Local setups also default to the user root with an empty password, which breaks the moment you copy a production wp-config.php down to your machine. Keeping separate config values per environment avoids that round trip entirely, and it’s one of the practical habits we recommend to anyone running a self-hosted WordPress site.

Stopping the Error From Coming Back

Most guides stop at the fix. The more useful question is why the connection failed in the first place, because a site that throws this error weekly has a capacity or code problem, not an accident.

• Watch your slow query log. A single unindexed query from a plugin can hold connections open long enough to exhaust the pool during traffic peaks.
• Read your logs on a schedule. Setting up PHP error log monitoring on the server surfaces warnings days before they become outages.
• Cache aggressively. Full-page caching keeps most visitors from touching MySQL at all, which is why page cache is active by default on every plan we run.
• Give the database its own resources. Once a site regularly peaks above a few hundred concurrent users, moving MySQL to a separate dedicated server removes the contention between PHP workers and database memory.

Shared hosting adds one more variable you can’t control: neighbors. If your database keeps hitting limits set by a provider rather than by your own traffic, no amount of query tuning will fix it.

Frequently Asked Questions

What Does a Database Connection Error Mean?

It means your website’s PHP code could not open a connection to its MySQL database, usually for one of four reasons: wrong credentials, a stopped database service, exhausted connections, or corrupted tables. The message is deliberately generic, so the cause has to be identified by checking wp-config.php values first and the database service second.

How Can I Fix a Database Error in WordPress?

Start by verifying DB_NAME, DB_USER, DB_PASSWORD and DB_HOST in wp-config.php, which resolves roughly half of all cases. If those are correct, confirm MySQL is running, check free disk space, then use the built-in repair tool at /wp-admin/maint/repair.php for table corruption.

How Do I Establish a Database Connection?

WordPress establishes the connection automatically using the four constants in wp-config.php, so the fix is making those values match the real database user and host. Create the user in your control panel, grant it all privileges on the target database, then paste the exact values into the file without extra spaces or quotes.

How Can I Repair the Database in WordPress?

Add define(‘WP_ALLOW_REPAIR’, true); to wp-config.php, visit /wp-admin/maint/repair.php, run the repair, then delete that line. For larger databases, phpMyAdmin’s Repair table command or a restore from a recent backup is typically faster, and daily automated backups make the restore path a 60-second job.

Get Database Issues Handled by People Who Watch the Logs

If this error keeps returning on your current host, the underlying capacity problem is worth solving properly. Our team handles the tuning, monitoring and recovery side for you, and you can reach a WordPress specialist any time through 24/7 expert hosting support or see what else is included with managed WordPress.