When WordPress displays “Error establishing a database connection,” it cannot communicate with the MySQL or MariaDB database that stores your posts, users, settings, and plugin data. The result may be a completely unavailable site or a dashboard that fails to load.
The cause is usually traceable to a small group of problems: incorrect values in wp-config.php, missing MySQL privileges, an unavailable database server, a table-prefix mismatch, or hosting resource limits. Work through the checks below in order. If your hosting panel is still accessible, create a backup before changing files or database settings. You can also review how to restore a WordPress backup from cPanel safely.
1. Check whether the problem is temporary
Reload the site in a private browser window and determine whether the error affects the front end, the WordPress dashboard, or both. Note when the problem began and whether it followed a traffic spike, server restart, migration, plugin update, or hosting change.
Check your hosting provider’s status page or contact support to ask about database maintenance, service outages, server load, and account-level resource problems. If the host is experiencing an outage, repeated edits to WordPress files are unlikely to help and may complicate recovery.
2. Verify the database settings in wp-config.php
WordPress reads its database connection details from wp-config.php, usually located in the site’s document root. Open the file through your hosting file manager or SFTP and review these constants:
define( 'DB_NAME', 'database_name' );
define( 'DB_USER', 'database_user' );
define( 'DB_PASSWORD', 'database_password' );
define( 'DB_HOST', 'localhost' );Every value must match the database and MySQL user created for the site. Common mistakes include using an old password, leaving out the hosting account prefix from the database name or username, inserting an accidental space, or entering the wrong database host.
Never share your real database password in support forums, screenshots, chat messages, or AI tools. If you suspect the password is incorrect, reset the MySQL user password in cPanel or your hosting panel and then update DB_PASSWORD with the new value.
Confirm the correct DB_HOST value
localhost is common, but it is not universal. Some hosts use a separate hostname or IP address for MySQL. Ask your provider for the correct database host rather than guessing. Valid credentials will still fail when DB_HOST is wrong.
3. Confirm the MySQL user has privileges
The database may exist even when its assigned MySQL user cannot access it. In cPanel, open MySQL Databases, confirm that the database and user exist, and check that the user is assigned to the correct database.
If your hosting panel includes a privileges option, grant the user the permissions WordPress normally needs, including SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, and DROP. Full privileges may be appropriate for a standard WordPress installation, but follow your host’s security guidance and do not grant access to unrelated databases.
Save the changes and test the site. If the database user was renamed, make sure the username in wp-config.php is updated as well.
4. Check database server availability
If the credentials appear correct, find out whether the database server is reachable and accepting connections. Your hosting provider can check the MySQL or MariaDB service, connection limits, server logs, disk space, and current load. On a development machine, you can test the credentials with a database client or command-line tool, although production hosts may restrict direct database access.
When contacting support, ask specific questions:
- Is the MySQL or MariaDB service running?
- Is the database server accepting connections from this hosting account?
- Has the database hostname or port changed?
- Are connection limits, disk space, memory, or other account limits being exceeded?
If several websites on the same hosting account show the error, a server-side or account-level problem is more likely than an isolated WordPress configuration mistake.
5. Check the table prefix after a migration
WordPress commonly uses the wp_ table prefix, but installations can use a custom prefix. The configured prefix appears in wp-config.php:
$table_prefix = 'wp_';Open phpMyAdmin and compare the actual table names with this value. For example, if the database contains site7_posts, site7_options, and site7_users, the configuration should contain:
$table_prefix = 'site7_';A wrong prefix can produce missing-table errors, failed logins, or a site that behaves as though WordPress has just been installed. This commonly happens after a migration, database import, or manual table rename.
Create a backup before changing the prefix or renaming tables. A mismatch is usually correctable, but careless database edits can make recovery more difficult.
6. Investigate hosting limits and database overload
Shared hosting plans may limit CPU, memory, PHP workers, database connections, or disk space. A site can work normally until a traffic burst, backup job, crawler, import, or inefficient plugin consumes the available resources.
Review the resource graphs in your hosting panel and check whether the account is close to its storage or inode limit. Ask your host whether the account has reached its concurrent MySQL connection limit. If the error appears during WooCommerce activity, imports, reports, or scheduled tasks, record the exact time and action that triggered it.
Once the site is accessible, investigate slow queries, oversized tables, object-cache problems, and plugins that repeatedly query the database. Do not delete database tables simply to reduce their size. Remove or clean data only when you understand what it contains, and test performance changes one at a time.
7. Rule out recent plugin and code changes
A plugin does not normally change WordPress’s database credentials, but a failed update, custom-code error, or resource-heavy extension can make the site appear unavailable. If the problem began immediately after an update, disable plugins without using the dashboard by renaming the wp-content/plugins directory through SFTP or your hosting file manager. Rename it back after testing.
For related server-side failures, see this guide to fixing WordPress 500 Internal Server Errors. If WordPress can connect to the database but PHP continues to crash, the troubleshooting path is different.
8. Know when to involve a professional
Contact your hosting provider first when the database server is unavailable or the account is reaching infrastructure limits. A WordPress developer can help when the problem involves a migration, corrupted tables, custom code, multisite configuration, or a production WooCommerce store that cannot tolerate extended downtime.
For a structured diagnosis, provide the exact error message, recent changes, hosting details, relevant timestamps, and a safe temporary access method. You can also review when to hire a WordPress backend developer.
Frequently asked questions
Can incorrect WordPress salts cause a database connection error?
No. Authentication salts affect login sessions and security, not the basic MySQL connection. Check the database constants and server availability first.
Should I change DB_HOST from localhost to 127.0.0.1?
Not automatically. These values can behave differently depending on the host’s network and socket configuration. Use the database hostname supplied by your hosting provider.
Can I repair the database from wp-admin?
Only if WordPress can connect to the database and you have enabled the appropriate repair setting. If the connection itself fails, use phpMyAdmin or ask the host for assistance instead.
Is changing the table prefix a security fix?
A custom prefix may reduce exposure to simplistic automated attacks, but it is not a substitute for updates, strong credentials, backups, and access controls.
Conclusion
Start with wp-config.php, then verify MySQL user privileges, database server availability, table prefixes, and hosting resource limits. Keep a backup before making database changes, protect your credentials, and involve your host or a qualified WordPress developer when the problem affects production data.