Error Establishing a Database Connection: Fast Fix Guide

“Error establishing a database connection” means WordPress can’t talk to your database server. In most cases, the fix is one of four things: wrong database credentials, the database server being down, corrupted database tables, or a server resource issue. The safest first step is to verify your settings and check whether the database service is actually running before you touch anything else.

This error usually affects the whole site, including the admin area, because WordPress needs the database for pages, posts, users, settings, and almost everything else. If the problem started after a migration, hosting change, password reset, or server outage, that clue matters a lot.

What this error looks like

You may see one of these symptoms:

• A plain error page that says Error establishing a database connection
• The homepage loads sometimes, then fails on refresh
• wp-admin will not load, or it shows the same database error
• The site was working earlier today, then suddenly went down

Sometimes only the front end fails. Other times the site is completely inaccessible because WordPress can’t read the database at all. If you also see a hosting notice about resource limits, a database outage, or connection errors in your server logs, that is a strong clue.

Why it happens

WordPress connects to MySQL or MariaDB using the database name, username, password, and host stored in wp-config.php. If any one of those is wrong, or if the database server is unavailable, WordPress cannot finish loading.

The most common causes are:

• Incorrect database credentials in wp-config.php
• The database server is down, overloaded, or rejecting connections
• The database host value is wrong, especially after a migration
• Corrupted database tables
• Disk space, memory, or connection limits on the host
• File or permission issues after a restore or deployment

Less commonly, the database user exists but no longer has permission to access the database. That can happen after a hosting panel change, restore, or manual account update.

Step 1: Back up first, if you can

If your host still gives you access to files or phpMyAdmin, take a backup before changing anything. If the database is reachable, export it. If the site is down and you have no easy backup path, do not start editing files randomly. The goal is to fix the current issue without making recovery harder.

Step 2: Check whether the database server is actually up

If your hosting control panel has a status page, start there. Many managed hosts show separate status for web, database, and mail services. If the database service is having an incident, the fix may simply be waiting for the host to restore it.

If you have access to phpMyAdmin, try opening it. If phpMyAdmin also fails to connect, the problem is likely at the database server level rather than inside WordPress.

For VPS or dedicated servers, your engineer may need to check whether MySQL or MariaDB is running, whether it has enough disk space, and whether the service logs show crashes or connection refusals.

Step 3: Verify your WordPress database settings

Open wp-config.php and confirm these values are correct:

• DB_NAME
• DB_USER
• DB_PASSWORD
• DB_HOST

Compare them with the database details shown in your hosting control panel. A single typo is enough to break the site.

Pay special attention to DB_HOST. On some hosts it is localhost. On others it is a hostname, an internal IP, or a socket-based value. After a migration, this is often the setting that changes.

define( 'DB_NAME', 'example_database' );
define( 'DB_USER', 'example_user' );
define( 'DB_PASSWORD', 'strong-password-here' );
define( 'DB_HOST', 'localhost' );

If you recently changed the database password in your hosting panel, you must update the same password in wp-config.php. The two must match exactly.

Step 4: Test the database user and permissions

If the credentials look right but the site still fails, check whether the database user still has full privileges on the database. In many hosting panels, a user can exist without being assigned to the correct database, or the permissions can be incomplete after a restore.

Reassign the user to the database if needed, then grant the required permissions. On most hosts, the safest route is to use the hosting panel rather than direct SQL unless you already know the exact changes you need.

Step 5: Repair possible database corruption

If the database server is up and the credentials are right, corrupted tables may be the issue. WordPress has a built-in database repair mode that can help with this.

To use it, add this line to wp-config.php just above the line that says /* That's all, stop editing! */:

define( 'WP_ALLOW_REPAIR', true );

Then visit:

https://yourdomain.com/wp-admin/maint/repair.php

Choose the repair option first. If needed, you can also use the optimize-and-repair option, but only after backing up if possible. When you are done, remove the WP_ALLOW_REPAIR line immediately. Leaving it enabled is not safe.

Important: this repair screen does not require a login, so only use it briefly and remove it right after. If your host restricts this feature or the issue is deeper than a few damaged tables, you may need a database-level repair from the hosting side.

Step 6: Check for server resource problems

If your database is huge, your host may be hitting CPU, RAM, inode, or disk limits. A busy WooCommerce store, a large import, or runaway scheduled tasks can overwhelm the database and make WordPress look broken even though the credentials are fine.

Look for these clues:

• Slow admin panels before the outage
• Backup jobs or imports running at the same time the site failed
• Hosting alerts about disk full or high load
• Repeated database timeouts in logs

If the server is out of disk space, no WordPress repair will stick until space is freed. If the database is overloaded, the fix may involve stopping a runaway process, reducing load, or moving to better hosting resources.

Step 7: Rule out a bad migration or restore

This error is common right after moving a site. If the database was imported but the config file still points at the old database name, old host, or old user, WordPress will fail immediately.

After a migration, check these items in order:

1. Database was imported successfully
2. The new database name matches DB_NAME
3. The database user exists on the new host
4. The password matches the hosting panel
5. The correct host value is used in DB_HOST
6. The user has full access to the database

If you cloned a site from staging to production, make sure the production wp-config.php was not left pointing at a staging database.

Step 8: Use logs to narrow it down

If you still do not have the answer, check the database and server logs. You are looking for clues like “access denied,” “unknown database,” “too many connections,” “table crashed,” or “server has gone away.” Those messages usually point to the exact class of failure.

If you want a safer, more structured way to read WordPress errors and logs, this pairs well with There Has Been a Critical Error on This Website: What It Means and How to Fix It. That guide helps you separate plugin/theme failures from database and server-level problems.

How to prevent this error later

You can reduce the chance of a repeat by building a few habits into your maintenance routine:

• Keep a current backup before updates and migrations
• Store database credentials securely and update them in one place when they change
• Use a host that provides clear database status and logs
• Monitor disk usage and resource limits
• Clean up old tables, abandoned plugins, and unnecessary data
• Test restores so you know backups are usable

If this happened after a heavy plugin or theme change, also review your recent updates. A broken update can indirectly trigger database issues, especially if it changes queries, imports data incorrectly, or overwhelms the server. Our guide on WordPress Site Broke After an Update? Here's What Happened and How to Fix It is a good next read.

If performance is part of the story, especially on large stores or content-heavy sites, the broader site bottleneck may be the real issue. In that case, Speed Up WordPress: Why Your Site Is Slow and How to Fix It can help you identify the upstream cause before it turns into a hard outage.

When to call a professional

Call a professional if the site is still down after you confirm the credentials, if the database server is unstable, if the repair screen does not help, or if you are not sure whether the issue is in WordPress, the database, or the hosting layer. Database mistakes can make recovery harder if you overwrite the wrong settings or repair the wrong copy of the site.

If you need a fast second set of hands, Mend can triage the problem first and give you a flat price before work starts. Start with a free diagnosis at /start/diagnosis, or go straight to /start/emergency if the site is business-critical and needs urgent rescue. Mend fixes WordPress issues with a backup-first workflow, and every paid fix includes a plain-English report of what caused the problem and what changed.

If you want secure access without sharing passwords, use /connect. Once the site is stable again, a /care plan can keep updates, backups, security, and uptime monitoring under control so this kind of outage is less likely to surprise you again.

Bottom line

“Error establishing a database connection” is usually not a mysterious WordPress bug. It is WordPress telling you that the connection to MySQL or MariaDB failed, and the fastest fix is to check the host, credentials, permissions, and database health in that order. If the site is down and you are not getting clear answers from your host, getting help early is often the safest move.