LiveChat 
Support 
Error Establishing a Database Connection: Causes and Fixes
Few messages cause as much panic as a blank white page that simply reads “Error establishing a database connection.” Your site is offline, the dashboard is unreachable, and there is no obvious clue about what went wrong. The good news: this error has a small set of well-understood causes, and most of them can be diagnosed and fixed in minutes once you know where to look.
This guide explains what the error actually means, walks through every common cause in order of likelihood, and gives you a repeatable diagnosis process. While the examples use WordPress, the underlying problem and most fixes apply to any application that connects to a MySQL or MariaDB database.
Key Takeaways
• The error means your website’s code cannot connect to its database server — not that your content is gone.
• The most frequent culprits are wrong database credentials in `wp-config.php` and a database server that is down or overloaded.
• If the error is intermittent and appears under traffic, it is almost always a resource or connection-limit problem, not bad credentials.
• WordPress includes a built-in repair tool (`WP_ALLOW_REPAIR`) for corrupted tables.
• When the cause is server-side, your hosting provider is the fastest path to resolution.
What Does “Error Establishing a Database Connection” Actually Mean?
Every dynamic website stores its content — posts, pages, users, settings, comments — in a database. WordPress keeps this data in a MySQL or MariaDB database and retrieves it on every page load. To do that, it opens a connection using four pieces of information stored in your `wp-config.php` file:
- DB_NAME — the name of the database
- DB_USER — the database username
- DB_PASSWORD — that user’s password
- DB_HOST — the address of the database server (often `localhost`)
The error appears when WordPress sends these credentials to the database server and the connection fails. Importantly, this usually does not mean your data is lost. The data is still sitting in the database; WordPress just cannot reach it right now. That distinction matters, because it keeps you focused on the *connection* rather than panicking about *recovery*.
What Are the Common Causes and How Do You Fix Them?
The table below summarizes the usual suspects and the fastest fix for each. The sections that follow explain the most important ones in detail.
| Cause | Typical Symptom | Fix |
|---|---|---|
| Wrong DB credentials in `wp-config.php` | Error appears suddenly after a migration or password change | Verify `DB_NAME`, `DB_USER`, `DB_PASSWORD`, `DB_HOST` |
| Database server down / MySQL not running | Whole site down, often other sites too | Restart MySQL/MariaDB or contact host |
| Too many connections / exceeded limits | Intermittent, worse under traffic | Increase limits, optimize queries, add resources |
| Corrupted database tables | Some pages load, others error | Run `WP_ALLOW_REPAIR` or repair via phpMyAdmin |
| Server out of memory/resources | Slowdowns, then errors under load | Upgrade plan, add RAM, optimize |
| Corrupted WordPress core files | Error plus other odd behavior | Re-upload fresh core files |
| Host-side outage or maintenance | Error with no recent changes on your end | Contact hosting support |
Are Your Database Credentials Wrong?
This is the number one cause when the error appears immediately after a site migration, a server move, or a database password reset. WordPress reads its connection details from `wp-config.php`, and if even one value is wrong, the connection fails instantly.
Open `wp-config.php` in the root of your WordPress installation and locate these lines:
“`php define( ‘DB_NAME’, ‘your_database_name’ ); define( ‘DB_USER’, ‘your_database_user’ ); define( ‘DB_PASSWORD’, ‘your_database_password’ ); define( ‘DB_HOST’, ‘localhost’ ); “`
Check each value carefully:
- DB_NAME must match the exact database name shown in your hosting control panel (in cPanel, this often includes an account prefix such as `user_wpdb`).
- DB_USER must be a user that has been granted privileges on that database.
- DB_PASSWORD must match the password set for that user — re-enter it rather than assuming it is correct.
- DB_HOST is usually `localhost`, but some hosts use a specific hostname, IP address, or a non-standard port (for example `localhost:3307`). Confirm the correct value with your host’s documentation.
A quick way to test the credentials independently is to log in to phpMyAdmin using the same username and password. If phpMyAdmin rejects them, you have found your problem — the credentials are wrong or the user lacks access.
Is the Database Server Down or Not Running?
If your credentials are correct but the connection still fails, the database server itself may be down. On a typical server, WordPress and MySQL/MariaDB run as separate services, and the database service can crash, stop, or be killed by the operating system when resources run out.
Signs that the database server is the problem:
- Other sites on the same server are also down. If you host multiple sites and they all show the error at once, the issue is server-wide, not specific to one site.
- The hosting control panel reports the MySQL/MariaDB service as stopped.
On a server you control (VPS or dedicated), you can restart the service with a command such as `sudo systemctl restart mysql` (or `mariadb`). On shared hosting, you cannot restart services yourself — this is the point to contact your hosting provider, who can confirm whether the database service is healthy and bring it back up.
Here is the single most useful diagnostic shortcut: if the error is *intermittent* — your site works fine most of the time but throws the database error during traffic spikes, scheduled email blasts, or busy periods — the cause is almost never your credentials. Wrong credentials fail 100% of the time, every request. An error that comes and goes under load is a classic signature of exceeded connection limits or exhausted server resources. Chasing `wp-config.php` in that scenario wastes hours; the real fix is raising MySQL’s `max_connections`, optimizing slow queries and plugins, or moving to a plan with more headroom.
Have You Exceeded Connection or Resource Limits?
MySQL and MariaDB enforce a maximum number of simultaneous connections (`max_connections`). When your traffic, plugins, or background processes try to open more connections than allowed, new requests are refused and visitors see the database connection error.
This is extremely common on busy sites running on shared hosting, where resources are divided among many accounts. Causes include:
- Sudden traffic surges
- Inefficient plugins or themes that open many database connections per page
- Slow queries that hold connections open longer than necessary
- Background tasks (cron jobs, imports, backups) running at peak times
Fixes range from quick to structural: optimize or remove heavy plugins, add a caching layer to reduce database hits, increase `max_connections` if you control the server, and — when the site has genuinely outgrown its plan — move to a VPS or dedicated environment with dedicated resources.
Is Your Database Corrupted?
Sometimes the connection succeeds but one or more database tables are corrupted, often after an unexpected server crash or interrupted write. WordPress may even hint at this with a message like *”One or more database tables are unavailable.”*
WordPress ships with a built-in repair tool. To enable it, add this line to `wp-config.php`, just above the `/* That’s all, stop editing! */` comment:
“`php define( ‘WP_ALLOW_REPAIR’, true ); “`
Then visit this URL in your browser (no login required):
“` https://yourdomain.com/wp-admin/maint/repair.php “`
Choose “Repair Database” (or “Repair and Optimize Database”). Once the process finishes, remove the `WP_ALLOW_REPAIR` line immediately — leaving it in place is a security risk because the repair page is publicly accessible while enabled.
Alternatively, you can repair tables directly in phpMyAdmin: select the database, check the affected tables, and choose “Repair table” from the dropdown menu.
Could Corrupted WordPress Files Be the Cause?
Less commonly, the core WordPress files responsible for the database connection become corrupted — for instance after a failed update or an incomplete file transfer. If credentials check out and the database is healthy, try re-uploading fresh copies of `wp-admin` and `wp-includes` from a clean WordPress download, leaving your `wp-content` folder and `wp-config.php` untouched.
How Do You Diagnose the Error Step by Step?
When you are staring at the error and unsure where to start, follow this sequence. It moves from the most likely and easiest checks to the ones requiring host involvement.
- Confirm the error is consistent. Reload a few times. If it is intermittent, jump straight to connection/resource limits.
- Check whether other sites are affected. If every site on the server is down, the problem is server-side — contact your host.
- Verify credentials in `wp-config.php`. Compare `DB_NAME`, `DB_USER`, `DB_PASSWORD`, and `DB_HOST` against your control panel, and test them by logging in to phpMyAdmin.
- Test the front end and the admin separately. If the admin shows a different message such as the database-repair prompt, run `WP_ALLOW_REPAIR`.
- Repair the database if corruption is suspected, via `WP_ALLOW_REPAIR` or phpMyAdmin.
- Re-upload core files if everything else checks out.
- Contact your hosting provider. If the database service is down, resources are exhausted, or you cannot restart services yourself, your host can diagnose server-side issues fastest.
Hosting That Keeps Your Database Connected
Many “Error establishing a database connection” incidents are ultimately server-side: an overloaded MySQL service, connection limits set too low, or a database server starved of memory. No amount of `wp-config.php` editing fixes a host that cannot keep the database online under load.
DarazHost is built to prevent exactly these failures. Our hosting runs a stable, well-resourced MySQL/MariaDB stack with sensible connection limits and active monitoring, so your database stays reachable even during traffic spikes. You get straightforward database management through cPanel and phpMyAdmin, making credential checks and table repairs simple. For sites that have outgrown shared resources, our VPS and dedicated plans give your database dedicated headroom. With a 99.9% uptime commitment and 24/7 support, our team can confirm service health and resolve database-side issues fast — so you spend less time staring at error pages.
Frequently Asked Questions
Does this error mean I lost my data? Almost never. The error means WordPress cannot *connect* to the database, not that the data inside it is gone. Once the connection is restored, your content reappears intact.
Why does the error appear only sometimes? An intermittent error that shows up under traffic is the signature of exceeded connection limits or exhausted server resources, not wrong credentials. Wrong credentials fail on every single request, consistently.
Where do I find my database credentials? They are defined in the `wp-config.php` file in the root of your WordPress installation, and the matching values appear in your hosting control panel (database name, user, and host). Reset the password through the panel if you are unsure of it.
Is it safe to leave `WP_ALLOW_REPAIR` enabled? No. The repair page is accessible without logging in, so leaving the setting on exposes a public tool. Always remove the `define( ‘WP_ALLOW_REPAIR’, true );` line as soon as the repair finishes.
When should I contact my hosting provider? Contact them whenever the database service appears to be down, multiple sites are affected, you suspect resource limits, or you cannot restart services yourself. Server-side problems are resolved fastest by the host.
