Fix WordPress first if the screen says “Error establishing a database connection,” but prove MySQL is alive before you edit anything risky. WordPress is the messenger. MySQL is the vault. If the messenger cannot open the vault, your site shows that scary white screen.
TLDR: Start with wp-config.php, then test the MySQL server. In many support cases, about 60% of these errors come from wrong database credentials, not a dead database. Example: Ana changed her hosting password, but WordPress still had the old one in wp-config.php, so her shop was down for 18 minutes. Check names, passwords, host, and server status before you panic.
What the error really means
WordPress needs MySQL to build each page. Posts, pages, users, settings, orders, comments, and plugin data live in the database. WordPress asks MySQL for that data. MySQL answers. Then WordPress paints the page.
When the connection breaks, WordPress cannot get the data. So it throws the famous message:
“Error establishing a database connection.”
Honestly, it feels like the site is yelling at you with a pillow over its face. It gives no useful detail. It does not say if the password is wrong. It does not say if MySQL is asleep. It just sits there, looking dramatic.
WordPress vs MySQL: who is guilty?
Think of WordPress as a restaurant waiter. Think of MySQL as the kitchen.
- WordPress takes the order.
- MySQL stores the ingredients.
- PHP carries the request.
- Your web server serves the final plate.
If the waiter cannot reach the kitchen, many things could be wrong. Maybe the kitchen door is locked. Maybe the waiter has the wrong key. Maybe the kitchen is on fire. Maybe someone renamed the building. Web hosting is fun like that.
Start with WordPress checks
Your first stop is wp-config.php. This file tells WordPress how to connect to MySQL. It usually sits in the main WordPress folder.
Look for these lines:
- DB_NAME: the database name.
- DB_USER: the database username.
- DB_PASSWORD: the database password.
- DB_HOST: the database host.
A tiny typo can break the whole site. One extra space can waste your afternoon. It drives me crazy that a single missing character can make a site look dead.
Common values for DB_HOST include:
- localhost
- 127.0.0.1
- mysql.yourhost.com
- A private server IP
Do not guess forever. Check your hosting panel. Look under databases. Find the exact host value. Copy it carefully.
Then check MySQL
If the WordPress settings look right, test MySQL. The database server may be down. It may be full. It may be rejecting connections. It may be overloaded by a plugin that thinks every visitor deserves 97 database queries.
Ask these simple questions:
- Is the MySQL service running?
- Can you log in with the same database user?
- Does the database still exist?
- Does the user still have permission?
- Is the server out of disk space?
- Are there too many open connections?
If you use shared hosting, check the host status page first. If 400 other sites are also broken, it is not your plugin’s fault. For once.
Fast test from the hosting panel
Most hosting panels include phpMyAdmin or a database manager. Try to open the database there.
If phpMyAdmin opens and shows tables like wp_posts, wp_options, and wp_users, MySQL is probably alive. That points back to WordPress settings, user rights, or host details.
If phpMyAdmin fails too, the issue is likely MySQL, hosting, or permissions. That saves time. You stop poking WordPress like it owes you money.
Common WordPress causes
These are the usual WordPress-side troublemakers:
- Wrong database password: Very common after host migrations.
- Wrong database name: Easy to mix up on servers with many sites.
- Wrong database user: Similar names cause pain.
- Wrong DB_HOST: Especially after moving hosts.
- Corrupt wp-config.php: Bad edits can break PHP syntax.
Also check if a security plugin changed file permissions. Some tools mean well. Then they lock the door, hide the key, and call it protection.
Common MySQL causes
These are the usual MySQL-side problems:
- MySQL is stopped: The service is not running.
- Too many connections: The server says, “No more guests.”
- No disk space: Databases hate cramped rooms.
- Broken table: A table may need repair.
- User permissions changed: WordPress can see the door but cannot enter.
- Server migration mismatch: The database moved, but WordPress did not get the memo.
On VPS or dedicated hosting, you may need command line access. A simple service check can tell you if MySQL is running. If not, restart it. Then check logs. Logs are boring, yes. They are also where the truth usually hides.
Use the WordPress repair tool with care
WordPress has a built-in repair mode. Add this line to wp-config.php:
define('WP_ALLOW_REPAIR', true);
Then visit:
yourdomain.com/wp-admin/maint/repair.php
You can repair or repair and optimize the database. After that, remove the line from wp-config.php. Do not leave it there. Anyone can access that repair page while it is active.
What to do during a migration
Database connection errors love migrations. They show up right when you think the hard part is done.
Check these items after moving a site:
- Confirm the new database name.
- Confirm the new database user.
- Set a fresh password.
- Grant the user full rights to the database.
- Update DB_HOST.
- Import all tables.
- Check table prefixes.
The table prefix matters. WordPress usually uses wp_. Some sites use custom prefixes like site7_. If wp-config.php expects the wrong prefix, WordPress may act strange even after it connects.
How to tell where the problem lives
Use this quick split:
- Only WordPress fails: Check wp-config.php, permissions, and table prefix.
- phpMyAdmin also fails: Check MySQL service, hosting, and server load.
- It fails only sometimes: Check max connections, traffic spikes, and heavy plugins.
- It started after an edit: Undo the edit first.
- It started after migration: Compare old and new database settings.
Prevention beats panic
Keep a copy of working database settings in a secure password manager. Take automatic backups. Test restore points. Monitor uptime. Watch server disk space. Keep plugins lean.
A good target is simple. Your site should load without random database failures for months at a time. If you see this error twice in one week, treat it as a warning. Something is unstable.
The smart order is WordPress settings first, then MySQL health, then deeper server logs. That path saves time. It also keeps you from blaming the wrong part. WordPress may be the face of the error, but MySQL may be the one hiding under the desk.