Skip to content
Website Rescue Rescue

MySQL and Database Errors

Error Establishing a Database Connection

Intermediate Risk: high

Last reviewed

Hosting access may not be needed Database access often needed

Direct answer

WordPress cannot reach MySQL or MariaDB. Verify DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST in wp-config.php against your hosting panel, confirm the database service is running, then repair or restore if tables are corrupt.

This error means WordPress loaded its PHP files but failed to open a MySQL/MariaDB connection, so it cannot read settings, posts, or users. Both the front end and wp-admin usually fail together until credentials, host/socket, service status, or table health are fixed. Walk through panel credentials first, then service status, connection limits, and repair/restore—do not reinstall WordPress core as a first step.

Intermediate

What the error means

WordPress stores almost all site content in MySQL or MariaDB. On each request it reads DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST from wp-config.php and asks the database server for a connection. When that handshake fails—wrong credentials, stopped database service, revoked privileges, wrong host/socket after a migration, corrupt tables, or too many connections—WordPress prints “Error establishing a database connection” and cannot continue. This is a connectivity/data-layer failure, not a missing theme file. Plugins rarely cause the initial refusal unless they have already exhausted connections or corrupted tables.

Common symptoms

  • Prominent “Error establishing a database connection” on every front-end URL
  • wp-admin shows the same database error instead of a login form
  • Sudden failure after host migration, domain change, or database password rotation
  • Intermittent errors during traffic spikes that clear after a few minutes
  • phpMyAdmin or the host database tool also fails with the same user/password
  • Host or MySQL logs mention “Access denied”, “Too many connections”, or “Connection refused”

Most likely causes

  1. 01 Wrong DB_NAME, DB_USER, DB_PASSWORD, or DB_HOST in wp-config.php
  2. 02 MySQL/MariaDB service stopped, crashed, or restarting on the server
  3. 03 Database user lost privileges or password changed in the hosting panel without updating wp-config.php
  4. 04 Corrupt tables after a crash, disk-full event, or bad migration import
  5. 05 Exceeded concurrent connection limits (max_connections / plan caps) on shared or busy hosts
  6. 06 Remote DB_HOST, firewall rule, or Unix socket path incorrect after a server move

What changed before the problem started

  • Hosting migration, server rebuild, or managed-host platform move
  • Database password reset in cPanel/Plesk/host UI without matching wp-config.php
  • Disk space exhausted on the VPS or hosting account
  • Host maintenance or MySQL/MariaDB version upgrade
  • Traffic spike, botnet, or runaway cron opening too many DB connections
  • Manual edits to wp-config.php or a botched search-replace on config constants

Troubleshooting steps

  1. 01

    Verify wp-config.php credentials against the hosting panel

    Open wp-config.php via File Manager or SFTP and compare DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST character-for-character with MySQL Databases (cPanel), Plesk Databases, or your managed host’s database screen. After migrations, DB_HOST is often no longer simply localhost—paste the exact hostname, IP, port, or socket the host shows. Save only if you change a value. Success signal: the four defines match the panel exactly (password may be hidden in the UI—reset it in the panel and paste the new value into wp-config if unsure).

  2. 02

    Test the same login in phpMyAdmin or the host database tool

    Log into the host’s database UI with the same user and password. If that login fails, the problem is server-side credentials, privileges, or service status—not a WordPress theme issue. Reset the DB user password in the panel, assign the user to the correct database with ALL PRIVILEGES, then update DB_PASSWORD in wp-config.php. Success signal: phpMyAdmin opens and lists your WordPress tables (wp_posts, wp_options, etc.).

  3. 03

    Confirm MySQL/MariaDB is running

    On VPS or cloud panels, check the database service status and recent restart events. A full disk, OOM kill, or failed upgrade can stop MySQL. On shared hosting, if phpMyAdmin is down for every site on the account, open a ticket asking whether the database cluster is healthy. Success signal: service shows running and a fresh phpMyAdmin session connects.

  4. 04

    Look for connection-limit or “too many connections” errors

    Review MySQL and PHP error logs around the outage window for “Too many connections” or max_user_connections. Persistent object caches misconfigured, heavy plugins, or traffic spikes can exhaust shared-host caps. After the database accepts connections again, temporarily rename heavy cron or cache plugin folders and reduce concurrent jobs. Success signal: errors stop correlating with traffic peaks and SHOW PROCESSLIST (or host metrics) is no longer saturated.

  5. 05

    Repair WordPress tables if credentials work but the site still fails

    When phpMyAdmin connects, select the site database, check for tables marked crashed, and use the host’s repair UI—or temporarily add define('WP_ALLOW_REPAIR', true); to wp-config.php and visit /wp-admin/maint/repair.php. Run repair (and repair & optimize if needed). Remove WP_ALLOW_REPAIR immediately afterward. Success signal: repair reports OK and the front end loads without the database error.

  6. 06

    Restore from a clean database backup if repair fails

    If tables are missing, repair errors multiply, or a migration import partially loaded, restore the most recent known-good database dump from before the failure. Prefer a tested full DB restore over piecemeal table edits on production. Success signal: site boots, wp-admin login works, and recent content matches the backup timestamp you chose.

When to stop troubleshooting

Stop if credentials match the panel but phpMyAdmin still fails, you lack permission to restart MySQL, table repair errors multiply, you are unsure which backup is clean, or disk/InnoDB recovery messages look severe. Database work without a verified restore path risks permanent data loss—escalate with host status, exact DB_HOST (redact passwords), and backup timestamps.

Information to collect before requesting help

  • 01 Exact error text and whether it is constant or intermittent
  • 02 Hosting provider and plan type (shared, VPS, managed WordPress)
  • 03 Whether phpMyAdmin accepts the same credentials
  • 04 Current DB_HOST value (redact passwords when sharing)
  • 05 Recent migrations, password resets, disk warnings, or host maintenance notices
  • 06 MySQL/PHP log snippets (Access denied, too many connections, crashed table, connection refused)
  • 07 Age, location, and type of the latest database backup

How a professional repairs the problem

We validate DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST against the live host panel, then confirm whether phpMyAdmin and the database service accept connections. From there we restore service access (credentials, privileges, host/socket, or host-side MySQL recovery), repair or restore damaged tables from a known-good backup, and confirm WordPress can bootstrap and reach wp-admin. After the site is up we check connection usage, migration leftovers, and monitoring so the same outage does not repeat after the next traffic spike or host move. You get a short report of root cause and what to change in wp-config only when the panel values actually differ.

Frequently asked questions

Can a plugin cause “Error establishing a database connection”? +
Plugins rarely break the initial connection unless they corrupt tables or exhaust connections. Always verify credentials and MySQL status first; investigate plugins only after the database accepts logins again.
What should DB_HOST be set to? +
Often localhost on classic shared hosting, but managed and cloud hosts frequently use 127.0.0.1, a Unix socket path, or a remote hostname. Use the exact value from your hosting database settings—localhost and 127.0.0.1 are not always interchangeable in PHP.
Will reinstalling WordPress fix this? +
Reinstalling core files does not fix a database that will not accept connections. Restore connectivity (and data) first. Reinstall core only if files are corrupt after the database is healthy.
Is this the same as an HTTP 500 error? +
WordPress usually shows this specific message when the DB connection fails early. Some hosts or reverse proxies may surface the same failure as a generic 500. Fixing database access resolves both presentations when the root cause is MySQL connectivity.
How do I know if the database was compromised? +
After access returns, look for unknown admin users, unexpected options, or spam tables. Connection errors alone do not prove a hack, but a sudden password change or defacement alongside the outage warrants a security review—not only a credential reset.
Is it safe to leave WP_ALLOW_REPAIR enabled? +
No. Anyone who can reach /wp-admin/maint/repair.php can trigger repairs while that constant is set. Remove it from wp-config.php as soon as repair finishes.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form.

Written by Website Rescue

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.