WordPress Says “Error Establishing a Database Connection”—How to Fix It Safely

17 hours ago

6 min read

“Error establishing a database connection” means WordPress reached the point where it needed site data but could not complete a connection to the configured database. The visible message is simple; the failure behind it may be a wrong password, unreachable database host, missing user permissions, exhausted server resources or damaged tables.

The fastest recovery comes from testing those layers in order. Reinstalling WordPress, clearing browser caches or creating an empty database can make the situation worse when the original database—and all the content inside it—is still recoverable.

What the error tells you

WordPress stores posts, pages, users, settings, comments, WooCommerce orders and much of its plugin data in MySQL or MariaDB. Its core files load the database values from wp-config.php and try to connect. When that connection fails before the requested page can be built, WordPress displays the database-connection error.

This is different from a normal 500 error, a critical PHP error or a blank page. It is also different from a site that connects successfully but queries the wrong tables after a migration.

First, record the failure pattern

Before changing credentials, note exactly where and when the error appears. The pattern narrows the cause.

Every page and wp-admin fail continuously: test credentials, database host and database-server availability first.
The error appears only during busy periods: investigate connection limits, memory pressure, CPU load and slow queries.
The public site fails but wp-admin shows a repair message: table corruption may be involved.
Only one migrated or staged copy fails: compare that environment’s wp-config.php and database endpoint.
The error started immediately after a password, host, clone or DNS change: examine that change before repairing tables.
The problem disappears without intervention: preserve timestamps and ask the host to correlate database restarts or resource limits.

Capture the time, affected URL, screenshot, recent deployment and whether another site on the same account also failed. Intermittent evidence is especially valuable because the server may look normal after it recovers.

Step 1: Protect the existing database before troubleshooting

Do not delete, reset or overwrite the database. If the hosting panel can still export it, create a dated SQL dump before changing credentials or repairing tables. Download the WordPress files as well, especially wp-config.php and wp-content.

A complete WordPress recovery set needs both files and database. If your current backup cannot restore, use Webcurry’s WordPress backup restore diagnostic before attempting high-risk changes.

Never paste a live database password into a support forum, screenshot or browser-based test file. If you create a temporary connection test, restrict access and delete it immediately after use.

Step 2: Verify wp-config.php without guessing

Open the wp-config.php file used by the failing installation. Confirm four values against the hosting control panel or managed-database dashboard: DB_NAME, DB_USER, DB_PASSWORD and DB_HOST.

DB_NAME must identify the existing WordPress database, not a newly created empty database.
DB_USER must be the database user assigned to that database.
DB_PASSWORD must match the current password exactly, including case and special characters.
DB_HOST may be localhost, a private hostname, an IP address, a socket path or a hostname with a non-standard port.

Do not assume DB_HOST is localhost because another host uses it. WordPress documentation notes that hosts may require a different hostname, port or socket. Use the value supplied for this account.

Check for accidental quotes, spaces, smart punctuation or partially edited lines. Use a plain-text or code editor rather than a word processor. Preserve an untouched copy before saving.

Step 3: Test whether the database server is reachable

Correct-looking credentials do not prove that the database service is accepting connections. Use the hosting panel’s database tool, a secure shell client or WP-CLI from the same server environment to test the configured endpoint.

A timeout usually points toward network routing, a stopped database service, firewall rules or an overloaded host. An access-denied response points toward the username, password, allowed source host or privileges. An unknown-database response points toward DB_NAME or a missing database.

If several sites sharing the same database server fail at once, contact the host with the exact timestamps. Ask whether MySQL or MariaDB restarted, reached its connection limit, ran out of storage, exceeded an account quota or was moved to another endpoint.

Step 4: Confirm the database user still has access

A database can exist and the password can be correct while the user is no longer assigned to it. This often happens after migrations, account restores, password rotations and manual database cleanup.

In the hosting panel, verify that the configured user is attached to the configured database with the privileges WordPress needs. Do not grant global privileges when database-specific privileges are sufficient.

If you reset the database password, update wp-config.php immediately and test from the same environment. Remember that applications, staging copies or scheduled scripts using the old password will also need an intentional update.

Step 5: Check server capacity and connection limits

An intermittent database error can be a capacity problem rather than a credential problem. Review database connections, slow queries, CPU, memory, disk usage and process limits around the recorded failure time.

A traffic spike is only one possible trigger. A plugin can create inefficient queries, an import can lock tables, scheduled tasks can overlap, or a backup can consume disk and I/O. If the site became slow after adding a plugin, follow Webcurry’s plugin performance isolation workflow instead of treating every timeout as a database outage.

For a slow dashboard with a fast public site, examine cron jobs, autoloaded options and database queries using the slow wp-admin diagnostic.

Step 6: Repair tables only when there is evidence of corruption

Do not begin with database repair. A repair command cannot correct the wrong hostname or password, and unnecessary repair adds risk during an outage.

Look for specific table errors in database logs, phpMyAdmin, the hosting tool or WP-CLI. WordPress’s command-line tools can check the current database using the credentials in wp-config.php. If the check identifies damaged tables, take a fresh export when possible before repairing them.

Repair only the affected database and verify the result. Some storage engines and failure modes require host or database-administrator intervention. Optimization is routine maintenance, not a substitute for repairing corruption or resolving server failure.

Step 7: Handle migration-specific failures

After moving WordPress, confirm that the new server has the database import—not merely the website files. A copied wp-config.php may still reference the old private database host, while a newly generated configuration may point to an empty database.

Confirm the expected tables exist in DB_NAME.
Confirm the configured table prefix matches those table names.
Replace environment-specific database hostnames and ports.
Recreate the database user and privileges on the destination.
Allow the new web server as a permitted database source when the database is remote.
Check that secrets or environment variables actually reached the production deployment.

A table-prefix mismatch generally produces missing-site or installation behavior after a successful connection, while bad connection details produce the database-connection error itself. Keep those stages separate.

If the migration also changed URLs and visitors meet missing pages after recovery, use Webcurry’s post-migration 404 recovery guide.

When reinstalling WordPress will not help

WordPress core files do not contain the live database password unless wp-config.php is separately changed. Replacing wp-admin and wp-includes therefore will not fix an unavailable MySQL server, incorrect DB_HOST, revoked user or damaged database table.

Reinstall core only when you also have evidence of missing or modified core files. Webcurry’s safe WordPress reinstallation guide explains how to preserve the database, media and configuration when core replacement is justified.

What not to do

Do not create a fresh WordPress installation over the existing directory.
Do not import an old database before preserving the current one.
Do not run database reset or drop commands while diagnosing connectivity.
Do not expose credentials through public test files, logs or screenshots.
Do not repeatedly restart services without collecting timestamps and logs.
Do not assume a disappearing error is resolved; intermittent failures usually return.
Do not blame browser cache for a server-side database connection failure.

Verify the recovery beyond the homepage

Once WordPress reconnects, review recent posts, users, form entries, orders and settings to confirm the expected database is loaded. Test administrator login, media, search, forms, scheduled jobs, checkout or bookings, and transactional email.

Check server and database logs for recurring connection errors. Monitor the site through a normal traffic cycle. If a password or database user was compromised, rotate related credentials, review administrator accounts and remove temporary troubleshooting files.

If the problem followed a WordPress update, complete the update recovery checklist so the original trigger is not left unresolved.

A practical escalation note for your host

A useful hosting ticket includes the domain, exact timestamps with time zone, whether the error was continuous or intermittent, the database hostname, the connection result or error code, other affected sites and the changes already ruled out. Do not include the password.

Ask for evidence: database-service uptime, rejected connections, connection-limit events, storage exhaustion, resource throttling and recent endpoint changes. That turns “the database is down” into a testable incident.

Fix the failed layer, not the whole website

The database-connection message is the start of the diagnosis, not the diagnosis itself. Preserve the existing data, verify configuration, test reachability, confirm permissions, inspect capacity and repair tables only when the evidence supports it.

That sequence protects content while reducing downtime and repeat failures. For an independent review of a business-critical WordPress outage, contact Webcurry with the failure timeline and hosting environment.