wordpress database error
Quickly identify what you’re seeing (and what it means)
When WordPress displays “Error establishing a database connection”, it means that PHP (WordPress) is unable to establish a valid session with MySQL/MariaDB. Specifically, the site can no longer read its content (posts, pages, settings, users), since everything is stored in the database.
This message is intentionally generic. The most common causes fall into a few groups: incorrect credentials in wp-config.php, unavailable database server, corrupted database, resource limits reached, or an issue on the hosting provider’s side. The goal is therefore to determine where the chain breaks: WordPress → network → DB server → authentication → tables.
Step 1: check access to the site and the back office (a valuable clue)
First reflex: test both the homepage and /wp-admin/. If the front end is down but the admin opens, the problem may be partial (cache, specific table, overload). If everything is down, lean more toward a global connection issue (credentials, DB server down, hosting outage).
Another clue: some hosts display a different error page, or a more raw message like “Error establishing a database connection”. Note the time, the context (update, traffic spike, migration) and any recent change (plugin, theme, DNS change, backup restore).
Step 2: check the connection settings in wp-config.php
In most cases, the error comes from an incorrect parameter in wp-config.php. The constants to check are:
DB_NAME (database name), DB_USER (user), DB_PASSWORD (password), DB_HOST (database server host).
Points to note about DB_HOST (often underestimated)
On many hosting environments, DB_HOST is worth localhost. But this isn’t universal: it may be an IP, an internal hostname (e.g. mysqlXX), or a specific socket. After a migration, a plan change, or a move to a managed environment, this value can change.
Verify without making mistakes
Compare the values of wp-config.php with those shown in the hosting provider’s control panel (database, user, password, host). If you recently regenerated a MySQL password, don’t forget to update it here. A single typo is enough.
If you need a step-by-step guide on the hosting side, you can consult Fix the Error Error connecting to the database … which details the typical checks and common paths in hosting providers’ interfaces.
Step 3: test the MySQL connection outside of WordPress
The idea is simple: determine whether the problem comes from WordPress or from the database itself. If you can connect to MySQL with the same credentials, then WordPress is failing for a secondary reason (resources, corruption, plugin, etc.). If the connection fails, the problem is indeed at the access/server level.
Possible methods depending on your access:
1) Via phpMyAdmin: try opening the database and browsing the tables.
2) Via SSH: a command such as mysql -h HOST -u USER -p (if the host allows it).
3) Via the host’s interface: some offer a connection test or a MySQL status page.
Discover our offers for WordPress website maintenance
If phpMyAdmin shows an authentication error, you’re dealing with an incorrect user/password pair, a user without permissions, or a non-existent database. If phpMyAdmin doesn’t load or takes a very long time, the service may be down or overloaded.
Step 4: check the server’s status (outage, overload, limits)
When the credentials are correct, the error often appears during a temporary outage: MySQL restart, maintenance, CPU/RAM overload, too many simultaneous connections, disk full, or process limit reached on shared hosting.
Telltale signs:
– The problem happens suddenly without any recent change.
– The site comes back on its own after a few minutes, then goes down again.
– Other sites on the same hosting are affected.
– Pages take a long time and then end in an error.
In this scenario, check the host’s status, ongoing incidents, and metrics if you have access to them (CPU, RAM, I/O, number of connections). Optimization or moving to a more robust plan may be necessary if the error comes back regularly.
Step 5: enable proper diagnostics (without making the outage worse)
If you can edit wp-config.php, you can temporarily enable debug to get clues (use with caution in production). The goal isn’t to show details to visitors, but to log errors.
In practice, it’s better to enable logging (file) rather than display. Once the information is collected, restore the initial settings to avoid any information leak.
Beyond debug, also think about server logs (error_log, PHP-FPM logs, MySQL logs if available). A Too many connections or Access denied error will immediately steer the diagnosis.
Step 6: repair a potentially corrupted database
Table corruption (often after a crash, a saturated disk, a power cut, or a hardware issue) can cause connection errors or similar behavior. WordPress offers a repair mode, and MySQL also offers tools (depending on access).
Repair via WordPress (built-in option)
WordPress can initiate a table repair if you enable a specific setting in wp-config.php. This can resolve tables marked as crashed . Important: disable this option as soon as the repair is complete.
Repair via phpMyAdmin
In phpMyAdmin, you can select all tables and run Repair table . If multiple tables are damaged, this may be enough to bring the site back online.
For a broader approach (and advanced scenarios), this guide is useful: Fix Database connection error ? It explores common causes, server-side checks, and leads when simple solutions aren’t enough.
Step 7: isolate a plugin/theme conflict (when the DB server seems OK)
A plugin or theme can trigger a storm of queries, open too many connections, or cause fatal errors that look like a DB problem (for example, repeated timeouts that end up bringing down MySQL on a small server). Even if the message mentions the database, the initial cause may be application-level.
Test without breaking things: recommended method
If you have a staging environment, reproduce the problem and disable items one by one. In production, do it only if you’re sure you can roll back quickly (backup, FTP/SSH access, etc.).
For a cautious approach before adding or modifying extensions, you can rely on a testing protocol before going live, in order to drastically reduce incidents that end up impacting the database.
Remove or replace high-risk extensions
Outdated or abandoned plugins can generate inefficient queries, SQL errors, or incompatibilities with a recent version of PHP/MySQL. Over time, this weakens the whole system, especially if your server has limited resources.
If you need to clean things up, follow a controlled procedure: backup, deactivation, dependency check, removal, then observation. On this topic, here is a useful internal resource: a method for properly removing old extensions.
Step 8: check table prefixes and consistency after migration
After a migration or a restore, it can happen that the table prefix no longer matches the one declared in wp-config.php. WordPress then looks for tables that don’t exist, which can be interpreted as a database problem (or lead to related errors).
In wp-config.php, the variable $table_prefix must match exactly the tables present (for example wp_, wp123_, etc.). Check in phpMyAdmin: if your tables start with wpabc_ but the file indicates wp_, correct one of the two (generally, you correct the file, unless there is a specific strategy).
Step 9: make sure the database exists and that the user has the rights
Sometimes, the database has been deleted (human error), renamed, or restored under a different name. Other times, the MySQL user does exist, but doesn’t have privileges on the database (missing GRANT, user recreated, rights reset by the host, etc.).
Discover our offers for WordPress website maintenance
In phpMyAdmin or the host’s panel, check:
– that the listed database matches DB_NAME ;
– that the user DB_USER is properly associated with this database;
– that it has the necessary rights (at minimum SELECT/INSERT/UPDATE/DELETE/CREATE/ALTER depending on WordPress operations).
Step 10: distinguish the one-off incident from the structural problem
If the error occurs once and then disappears, maintenance or a DB restart on the host side is plausible. On the other hand, if it comes back (especially during traffic peaks), you need to address the structural cause: an undersized server, heavy queries, lack of cache, an overactive cron, costly internal search, or an overly resource-hungry extension.
A pragmatic action plan:
– Set up an appropriate caching strategy (page cache, object cache depending on context).
– Reduce costly queries (heavy stats plugins, search, complex filters).
– Check scheduled tasks (WP-Cron) and external automations.
– Optimize the database (clean revisions, transients, plugin tables).
– Increase resources if necessary.
To avoid fixing things blindly, you can also analyze recurring causes of slowness that end up bringing MySQL down on small configurations: The Most Frequent Performance Errors.
Step 11: take security into account (intrusion, injection, compromised accounts)
An inaccessible database can also be the result of a security incident: DB password changed, files altered, backdoors created, or malicious queries saturating the server. This is not the most common scenario, but it becomes likely if you also observe: unknown redirects, new admin accounts, recently modified files, or host alerts.
When in doubt, take an incident approach: change passwords (FTP/SSH, database, WordPress), verify file integrity, run a scan, audit accounts, inspect logs. A structured checklist helps ensure you don't forget anything: Security Audit What to Absolutely Check.
Step 12: when to ask for help (and from whom)
If you have checked wp-config.php, tested MySQL access, and checked permissions without results, it’s time to involve the host or a technical team. The host can confirm: MySQL outage, connection limit, disk incident, restoration needed, or endpoint change.
In addition, the French-speaking WordPress community can help interpret symptoms and suggest leads based on your context: Issue “error establishing a database connection”.
Prevent recurrence: backups, updates, monitoring
Fixing is one thing; preventing it from coming back is another. The best protections against this type of outage are generally not very glamorous, but very effective: tested automatic backups, regular updates, uptime monitoring, and resource tracking (CPU/RAM/IO) to anticipate saturation.
It’s also useful to set up routines: check the database status, clean tables left by plugins, monitor error logs, and keep traceability of changes (who did what, when).
To arbitrate between the cost of a preventive approach and that of an outage (loss of revenue, SEO, trust), this analysis helps frame the decision: Maintenance Cost vs Risks.
Express action plan (summary)
1) Confirm the scope: front + admin, and note the context (update, migration, spike).
2) Check DB_NAME/DB_USER/DB_PASSWORD/DB_HOST in wp-config.php.
3) Test the MySQL connection via phpMyAdmin/SSH, and verify that the database exists.
4) Check the user’s permissions on the database.
5) Check the server status (outage, limits, too many connections , disk).
6) Consider repairing tables if corruption is suspected.
7) Isolate a resource-hungry plugin/theme if the database is OK but the site drops under load.
8) Strengthen prevention: backups, monitoring, optimization, security.
When to outsource: save time without taking risks
If your site is critical (e-commerce, lead generation, media), every minute of downtime counts. In that case, delegating diagnosis and prevention to a team used to handling this type of incident helps avoid haphazard fixes and reduces time to recovery.
For ongoing support (updates, backups, monitoring, patches), you can consult Discover our site maintenance offers.
