Introduction

“Error establishing a database connection” is one of the most alarming messages a WordPress site owner can see, because it replaces the whole site — every page, every post, and the admin area — with a single plain sentence. The good news is that the message is precise: WordPress cannot reach the MySQL or MariaDB database that stores your posts, pages, user accounts, and settings. The PHP files are probably fine. Something in the connection between WordPress and the database has broken.

The causes are almost always one of four things: wrong database credentials in wp-config.php, a database user that lost its permissions, corrupted database tables, or a database server that is down or overloaded. This guide works through them in order, from the least destructive step to the most. Do not skip ahead to a database repair before you have ruled out the simpler causes — a repair cannot fix a wrong password, and an unnecessary repair on a healthy database adds risk for no benefit.

Before you touch anything: back up

If your site is down, you may be tempted to skip this step. Do not. Every fix below either edits a configuration file or changes the database, and a backup is your undo button if a fix makes things worse.

If you can still reach your hosting control panel, download a full backup — files plus database — through your host’s backup tool before you change anything. If you have a recent backup from your host or a backup plugin, confirm it exists and note its date. If you cannot make a backup because the database itself is unreachable, export what you can (for example, download the site files via your host’s file manager) and write down exactly what you change at each step, so you can reverse it.

Steps in this guide that need a backup first: editing wp-config.php, resetting a database password, running a database repair, and anything you do in phpMyAdmin. Steps that only involve looking — checking whether the site is down for everyone, checking the admin area — do not.

Step 1: Check whether the problem is your site or your host

First, find out whether the error is specific to your site or whether the whole server is having trouble.

Check the front end and the admin area separately. Visit your homepage and then visit yourdomain.com/wp-admin/. If the front end shows the connection error but /wp-admin/ shows a different message — “One or more database tables are unavailable. The database may need to be repaired” — your credentials are working and one or more tables are corrupted. Skip to Step 5.

Check whether other sites on the same host are down. If you have more than one site on the same hosting account and they all show the same error, the database server is the likely problem, not your site. In that case, skip to Step 6 and contact your host.

Check your host’s status page. Most hosts publish a status page or a notice in the hosting control panel when a database server is down for maintenance or overloaded. If there is an outage, the fix is patience — no change you make to your site will help, and editing files during an outage can create new problems.

If nothing points to the host, the problem is in your site’s configuration or database, and the next steps apply.

Step 2: Check the database credentials in wp-config.php

Wrong credentials are the number-one cause of this error, especially right after a site migration, a database password change, or a hosting move. WordPress logs in to its database using four values stored in wp-config.php, a file in your site’s root folder. If any one of them is wrong, the connection fails.

You will need access to your hosting control panel’s file manager or an FTP/SFTP client to open this file. Open wp-config.php and find these four lines:

define( 'DB_NAME', 'your_database_name' );
define( 'DB_USER', 'your_database_user' );
define( 'DB_PASSWORD', 'your_database_password' );
define( 'DB_HOST', 'localhost' );

Now check each value against the real database details in your hosting panel, usually under MySQL Databases or a similar section:

• DB_NAME must match the database name exactly. Database names often have a prefix added by the host, such as username_wp123. Copy it exactly; do not retype it from memory.
• DB_USER must match the database user exactly, prefix included.
• DB_PASSWORD must match the password of that database user. A single wrong character — or an accidental space at the end of the line — breaks the connection. If you are unsure of the password, reset it in the hosting panel (see Step 3) rather than guessing.
• DB_HOST is localhost on most shared hosts, but not all. Some hosts use a specific hostname or a socket path. Check your host’s documentation or the database section of your control panel for the correct value, and use exactly what it says.

Fix any value that does not match, save the file, and reload your site. If the site comes back, you are done — and you have learned which detail changed. If nothing changes, move on; do not keep editing the file at random.

Step 3: Reset the database password and check user permissions

If the credentials in wp-config.php look right but the site still fails, the stored password may no longer match what the database expects — this happens after a password reset in the hosting panel, a migration, or an automated security change by the host.

Reset the password in the hosting panel. Go to the MySQL Databases section, find the database user, and set a new password. Then copy that exact password into the DB_PASSWORD line in wp-config.php and save. Reload the site.

Check that the user is attached to the database with full permissions. A database user that exists but is not linked to your database — or is linked without the right privileges — produces the same error as a wrong password. In the MySQL Databases section, confirm that your database user is added to your database and has all privileges (or at least SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, and INDEX). If it is not attached, add it and grant the privileges, then test the site again.

If the password reset and permissions check do not help, the credentials are not the problem, and the database itself needs attention.

Step 4: Check whether the database server is responding

If the credentials are correct and the user has permissions, the database server may be down, overloaded, or refusing connections. Signs include the error appearing on every site on the account, or the error appearing intermittently — the site loads sometimes and fails at other times, often at busy hours.

You can test the database from phpMyAdmin in your hosting panel: if phpMyAdmin opens your database and shows its tables, the server is up and the problem is elsewhere. If phpMyAdmin itself fails to connect or times out, the server is the problem.

What to do: check whether you have recently hit a hosting limit — for example, a traffic spike, a backup running at the same time, or a plugin making heavy database queries. If the error started during a traffic spike or right after installing a new plugin, the server may simply be overloaded. In that case, the fastest reliable fix is to contact your host and ask them to check the database server’s status and resource usage. Tell them you have already verified the credentials in wp-config.php and the user permissions, so they do not repeat those steps.

Do not restart the database server yourself unless your hosting plan gives you that control and you know how to do it safely. On shared hosting, you do not have that option, and on a VPS, a bad restart can make things worse.

Step 5: Repair corrupted database tables

If the front end shows the connection error while /wp-admin/ reports that one or more tables are unavailable, or if the credentials and server both check out, one or more database tables may be corrupted. Corruption usually follows an interrupted update, a plugin crash, a sudden server reboot, or a failed bulk import.

Back up first. A repair changes the database. If you have not already made a backup, do it now — through your host’s backup tool or by exporting the database from phpMyAdmin if it still opens.

Option A — WordPress’s built-in repair tool. Open wp-config.php and add this line just above the comment that reads /* That's all, stop editing! Happy publishing. */:

define( 'WP_ALLOW_REPAIR', true );

Save the file, then visit https://yourdomain.com/wp-admin/maint/repair.php in your browser. You will see two buttons: Repair Database and Repair and Optimize Database. Choose Repair Database first — it checks every table and attempts to fix the broken ones. Wait for it to finish, then reload your site.

Remove the line immediately after the repair. The repair page does not require a login, so anyone on the internet can open it while the line is in place. Delete define( 'WP_ALLOW_REPAIR', true ); from wp-config.php and save the file as soon as the repair is done.

Option B — Repair tables in phpMyAdmin. Open phpMyAdmin from your hosting panel, click your WordPress database in the left sidebar, scroll to the bottom of the table list, tick Check all, and choose Repair table from the “With selected” dropdown. This does the same job without enabling the public repair page, and it is the safer choice if you are comfortable in phpMyAdmin.

If the repair reports that tables could not be fixed, restore from your backup instead of running the repair again. A failed repair on a table that holds your posts or settings is a sign that the backup is now your best path back.

Step 6: Escalate to your host

If you have worked through the steps above — credentials verified, password reset, user permissions checked, server tested, tables repaired — and the site is still down, the problem is on the hosting side: a database server fault, a corrupted server configuration, or an account-level issue you cannot see from the control panel.

Contact your host’s support and give them a short, specific summary: when the error started, what you have already checked (credentials in wp-config.php, database user permissions, phpMyAdmin access, repair result), and whether other sites on the same account are affected. That summary saves a round of back-and-forth and gets you to a server-side engineer faster. Ask them to confirm the database server’s status and whether your database user can connect from the server.

While you wait, do not keep changing settings. Repeated edits during an outage make it harder for support to find the original fault, and harder for you to know what actually fixed it.

How to prevent it happening again

• Keep a recent backup. A backup taken before the problem is worth far more than any repair tool. Automate daily or weekly backups through your host or a backup plugin, and check occasionally that the backups actually exist and can be restored.
• Use a strong, unique database password and do not change it casually. Most credential failures follow a password change that was not copied into wp-config.php. If you change the database password in the hosting panel, update wp-config.php in the same sitting.
• Keep WordPress, themes, and plugins updated, and update one thing at a time. Interrupted updates are a common cause of table corruption. Update on a quiet day, and do not close the browser tab while an update is running.
• Do not leave WP_ALLOW_REPAIR enabled. Check wp-config.php after any repair and confirm the line is gone.
• Watch for the warning signs. A site that gets slower over weeks, or that shows the error only at busy times, may have a database that is growing too large or a host plan that no longer fits the traffic. That is a good moment to review your hosting plan and clean up old revisions, spam comments, and unused plugins — and our guide to improving website loading speed covers the checks that catch those problems early.

When the error is not what it seems

A few lookalike problems are worth knowing about. If only /wp-admin/ shows an error while the front end works, the problem is usually a single corrupted table rather than the whole connection — the repair steps in Step 5 still apply. If the error appears only after a migration, check the credentials first; a migration is the most common trigger for a credentials mismatch, and our WordPress migration checklist covers the full move in order. And if the site loads but is very slow rather than showing an error, the database may be under strain rather than broken — measure first, then fix the bottleneck.

The bottom line

Work in order: back up, check whether the host is down, verify the four credentials in wp-config.php, reset the database password and check user permissions, test the database server, repair tables only when the symptoms point to corruption, and escalate to your host when the site-side checks are exhausted. The most common fix is also the simplest — a wrong database password after a migration or a hosting change. The most important habit is the one before any of it: a backup you can restore from.

Frequently asked questions

What does “Error establishing a database connection” mean?
It means WordPress cannot reach the database that stores your content and settings. The site’s files are usually intact; the connection between WordPress and the database is broken.

Is my content lost when this error appears?
Usually not. The content lives in the database, and the error means WordPress cannot read it right now, not that it has been deleted. That is why a backup and a careful, ordered diagnosis matter more than a rushed fix.

Can I fix it without hosting access?
No, not reliably. Every real fix needs access to wp-config.php, the hosting panel, or phpMyAdmin. If you do not have hosting access, contact whoever manages the hosting — they hold the keys to the fix.

Why did the error appear right after I moved hosts?
A migration is the most common trigger. The database name, user, password, or host almost always changes on a new host, and wp-config.php must be updated to match. Check the four values in Step 2 first.