The "Error Establishing a Database Connection" message means your site cannot open a connection to its MySQL database, so nothing loads and Google sees a 500 error. The top causes are wrong credentials in wp-config.php, a crashed or overloaded database server, and corrupted tables. We diagnose the real cause and fix it for $49-$99, usually in under an hour.
Every dynamic page on your site is assembled from data stored in a MySQL or MariaDB database: posts, products, settings, users. On each uncached page view, your site's code opens a connection to that database using the hostname, database name, username, and password saved in its configuration. When that connection handshake fails, WordPress stops immediately and prints "Error establishing a database connection" instead of your site. Nothing loads: not the homepage, not wp-admin, not checkout. WordPress serves this screen with an HTTP 500 status code, so Google sees a server error on every URL and will start suppressing your rankings if it persists. The critical thing to understand is that your content is almost always still sitting safely in the database. The failure is in the connection to the data, not the data itself, which is why most of these fixes are fast once the real cause is identified.
Fix This Error Now →Database Connection Error can be caused by several issues. Here are the most common.
The most common cause. The database name, username, password, or host in your site's configuration does not match what the database server expects. A single wrong character fails the handshake. This typically appears after a migration, a hosting password reset, or a manual edit to the config file.
MySQL or MariaDB runs as a separate service from your web server. On low-memory VPS plans it is often the first process killed when RAM runs out, so the web server keeps responding while the database is dead. That is exactly why you see this error instead of a plain timeout: PHP is running fine, the database is not.
MySQL ships with a default cap of 151 simultaneous connections per the MySQL Reference Manual. A traffic spike, a crawler hammering uncached pages, or code that holds connections open can exhaust the pool. New visitors get "Too many connections" refusals until connections free up, which makes the error come and go.
A crash mid-write, a full disk, or an interrupted update can leave a table damaged. In this state the connection itself may succeed, but WordPress fails on the broken table. The telltale sign: your homepage shows the connection error while wp-admin shows "One or more database tables are unavailable. The database may need to be repaired."
Most hosts use localhost as the database host, but many managed platforms use a dedicated hostname like mysql.example-host.com, a specific IP, a custom port, or a socket path. Migrating a site and keeping the old host value is a classic way to break the connection even though every other credential is right.
The WordPress documentation lists this explicitly: hosts shut down databases that exceed their storage quota. Bloated log tables, orphaned session rows, and unpruned backups grow silently until the day the quota trips. A suspended hosting account usually cuts database access first too.
The database user your site connects with needs privileges on that specific database. Hosts occasionally rebuild accounts during server moves, and a control panel action can drop the user or its grant. The database is healthy and the password is right, but the user is no longer allowed in.
When the database lives on a separate machine from the web server, anything that breaks the network path breaks the site: a firewall change, a new security group rule, or a DNS failure on the database hostname. Sites on scaled or enterprise hosting hit this after infrastructure changes they were never told about.
The WordPress documentation recommends ruling out compromise once configuration and hosting check out. Malware sometimes rewrites the config file, changes database passwords, or injects data that corrupts tables. If the credentials changed and nobody on your team changed them, treat it as a security incident.
70-80% of our customers have WordPress sites. Here are WordPress-specific causes for this error.
WordPress reads DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST from wp-config.php on every request. A typo from a recent edit, a stray character from a copy-paste, or an editor that saved the file with the wrong encoding is enough to kill the connection sitewide.
wp-config.php declares a $table_prefix, wp_ by default, and WordPress looks for tables named with it. After a migration or a restore into a database whose tables use a different prefix, WordPress connects fine but cannot find its tables, which surfaces as database errors or an unexpected install screen.
Some caching and database plugins install a wp-content/db.php drop-in that replaces the WordPress database layer. If the plugin is removed but the drop-in stays behind, or the drop-in references a class that no longer exists, every request fails at the database step even though the credentials are perfect.
An interrupted import can leave the database half-populated, with core tables like wp_options missing entirely. The connection works, the database exists, but WordPress cannot boot without its core tables. This is the top cause we see in the first hour after a DIY site move.
A poorly coded plugin or a runaway WP-Cron task can open queries that run for minutes, holding connections while new page views demand more. The site works at 9am, collapses at noon under load, and recovers at night, which points to pool exhaustion rather than credentials.
WordPress loads wp-content/db-error.php as a custom error page when the database fails. Hosts and old developers sometimes leave one behind with a generic maintenance message, so the site shows "down for maintenance" while the real problem is a dead database connection underneath.
Load the site and wp-admin separately. The repair message in wp-admin means table corruption. The plain connection error on both points at credentials, the server, or the network
Pull the exact database error from the server logs or a direct connection test, so we know whether the refusal is bad credentials, an unknown host, a dead server, or too many connections
Test the credentials in wp-config.php directly against the database server, bypassing WordPress entirely, to confirm or eliminate the config file in minutes
Verify the DB_HOST value against the host's documented database hostname, including port and socket variations that differ from localhost
Check the database server itself: is the MySQL or MariaDB service running, is the disk full, did the process get killed for memory. Restart it or have the host restart it
If tables are corrupted, enable WP_ALLOW_REPAIR in wp-config.php, run the repair script at wp-admin/maint/repair.php, then remove the constant immediately because that page requires no login
For engine-level corruption, repair MyISAM tables with REPAIR TABLE and recover InnoDB tables from backup, since MySQL's REPAIR TABLE does not apply to InnoDB
Inspect wp-content for stale db.php and db-error.php drop-ins left by old plugins and remove or rebuild them
Check connection usage against the server's max_connections limit, identify what is holding connections open, and fix the source rather than only raising the cap
Confirm database quota and account standing with the host, then set up automated database backups and uptime monitoring so the next incident is caught in minutes
This error means WordPress cannot connect to your MySQL database. Your content is likely safe but inaccessible. Common causes include wrong credentials, corrupted database, or server issues.
Visit yoursite.com/wp-admin. If you see a different error mentioning database repair, the database might be corrupted. If you see the same error, it is a connection issue.
Open wp-config.php and check DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST. These must match your hosting database settings exactly. Even one wrong character causes this error.
Log into your hosting panel (cPanel/Plesk). Go to MySQL Databases. If you can see your database and access phpMyAdmin, the server is running. If not, contact your host.
Add define('WP_ALLOW_REPAIR', true); to wp-config.php. Then visit yoursite.com/wp-admin/maint/repair.php. Click Repair Database. Remove that line from wp-config.php when done.
In cPanel MySQL Databases, verify your database user has ALL PRIVILEGES on the database. Missing privileges cause connection failures.
Most hosts use localhost but some require a specific server address. Check your host documentation. Common alternatives: 127.0.0.1 or mysql.yourdomain.com.
If the database is corrupted beyond repair, restore from backup. Most hosts keep daily backups. In cPanel, check Backup or JetBackup.
DIY is great, but sometimes you need expert help. Consider calling us if:
You cannot access cPanel or phpMyAdmin
The database repair tool does not work
You do not have a recent database backup
The error started after a failed migration or update
Your hosting says everything is fine but the error persists
Fixed in 2 hours or your money back. We do not waste time.
No hourly billing. You know the price before we start.
Cannot fix it? You do not pay. Zero risk to you.
Our Site Down & Server Issues team has fixed thousands of sites with this exact issue. 2-hour turnaround, guaranteed.
It means the code that runs your website could not open a connection to its MySQL or MariaDB database, so it has no way to load your posts, pages, or settings. WordPress halts and shows this message on every URL instead of your content. The failure sits in one of four places: the credentials your site uses, the database server itself, the network path between them, or corrupted tables inside the database. Finding which of the four is the whole diagnosis.
Almost certainly not. This error means the connection to the database failed, not that the database was erased. Your posts, products, orders, and settings are still stored in the database files on the server. Once the connection is restored, everything reappears exactly as it was. The rare exception is genuine table corruption from a disk failure, and even then the standard repair tools recover most or all of the data.
Because most causes are server-side. The database process can crash when the server runs out of memory, a traffic spike can exhaust the connection pool, a database can hit its storage quota, and hosts sometimes migrate servers or reset passwords in ways that break stored credentials. Your site was the same yesterday; the environment underneath it was not. That is also why the error often appears at your busiest hour.
Intermittent database connection errors almost always point at resource exhaustion rather than wrong credentials. Wrong credentials fail 100% of the time. A connection pool that empties under load fails only at peak traffic, and MySQL's default limit is 151 simultaneous connections. A memory-starved server that kills and restarts the database process fails in bursts. We identify which pattern yours follows from the timing of the failures and the server logs.
That message, "One or more database tables are unavailable. The database may need to be repaired," means WordPress can connect but one or more tables are damaged. The fix is different from a credentials problem: set the WP_ALLOW_REPAIR constant to true in wp-config.php, visit wp-admin/maint/repair.php, and run the repair. Then remove that line immediately, because WordPress warns that the repair page is accessible without logging in while the constant is set.
Hosts check whether the database server process is running, and it usually is. What they do not check is whether your site's stored credentials still match, whether your wp-config.php points at the right host, whether a plugin drop-in is breaking the database layer, or whether your tables are corrupted. Those are application-level problems, and they are the majority of the database connection errors we fix after a host has said everything is fine.
Sometimes. If you are comfortable with FTP and your hosting control panel, you can compare the credentials in wp-config.php against the database section of your panel, confirm the database exists in phpMyAdmin, and run the built-in repair tool for corruption. The risk is that wp-config.php edits with a typo take the site from one error to a worse one, and misdiagnosing the cause wastes hours. If the first careful check does not fix it, escalate rather than experiment.
Most database connection fixes cost $49-$99. Credential corrections, host value fixes, and standard table repairs sit at the low end. Recovering a half-migrated database, cleaning up after a compromise, or diagnosing connection pool exhaustion under load sits at the high end. You get a firm quote before we start, and if we cannot fix it, you pay nothing.
Our average database connection fix takes about 38 minutes. Credential and host value problems are usually solved within half an hour because a direct connection test isolates them fast. Table repairs typically finish within the hour. Full database restores from backup depend on the database size but almost always complete within our 2-hour guarantee window.
Four things cover nearly every repeat incident: automated daily database backups stored off the server, uptime monitoring that alerts you within minutes instead of when a customer emails, headroom on your hosting plan so the database process is not fighting for memory, and periodic cleanup of bloated tables so you never drift into a storage quota. We set all four up as part of the fix if you want them.
Every technical claim on this page traces back to primary documentation and the named vendor references below.
Plugin, theme, critical error, PHP, and update fixes in one place.
Visit the WordPress Repair hub →Get database connection error fixed today. Expert engineers. 2-hour guarantee.
Fix My Error Now →