How to Fix "Error Establishing a Database Connection" in WordPress
%203.png&w=256&q=75){kind=small}
What Causes This Error
"Error establishing a database connection" means WordPress loaded far enough to run wp-load.php, but the very first thing it tried to do — open a connection to MySQL or MariaDB — failed outright. This is not a plugin conflict, not a theme bug, and not a caching issue. It is WordPress core itself, before any of your site's code runs, unable to reach the database layer at all. That distinction matters because it rules out most of the usual troubleshooting steps (deactivating plugins, switching themes, clearing cache) and narrows the search to four places: wrong credentials in wp-config.php, the MariaDB service not running, a corrupted table the database engine refuses to read, or the database server rejecting new connections because it has hit its connection limit.
The order you check these in matters. Credential mismatches are by far the most common cause, usually after a site migration, a manual wp-config.php edit, or a database restore that used a different username. Service outages come second, often after a server reboot, a memory-pressure OOM kill, or a manual restart that did not complete. Table corruption is rarer but shows up after an unclean shutdown or a disk running out of space mid-write. Connection exhaustion mostly hits shared or under-resourced servers during traffic spikes. Work through the sections below in order and you will land on the actual cause within a few minutes rather than guessing.
Check wp-config.php Credentials
Open wp-config.php and confirm DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST exactly match what the database actually expects — a single typo, stray space, or leftover value from a migrated site is the single most common cause of this error. On a CloudStick server, wp-config.php lives at /home/<username>/apps/<sitename>/wp-config.php, and DB_HOST is almost always localhost unless you deliberately moved the database to a remote or managed server.
You need SSH access to the server (or dashboard file access) and the correct site username before editing wp-config.php directly. Never guess at credentials — if you are not sure what the database username or password should be, look them up rather than resetting them blind, since a password reset also requires updating the matching MySQL user, not just the file.
If you inherited the site or are not certain the credentials in the file are correct, do not edit wp-config.php by trial and error. CloudStick's Visual Database Manager lets you view the actual database name, username, and host for a site directly from the dashboard, and reset the database user's password with a click — no phpMyAdmin, no CLI, and no risk of pasting the wrong value into a config file. Whatever password it generates, copy it into DB_PASSWORD in wp-config.php and you are done; the two have to match exactly, since WordPress authenticates using the file's value, not whatever the database remembers from before.
Test the MySQL Connection Directly
If the credentials in wp-config.php look correct, connect to MariaDB directly with the same values WordPress is using — this tells you definitively whether the problem is the credentials themselves or the database service not accepting connections at all. Do not skip this step and assume the file is fine just because it looks right; a password with an unescaped special character can be copy-pasted perfectly and still fail authentication.
An Access denied response means the username, password, or host combination is wrong for that specific database — check whether the user was granted access from localhost specifically, since MySQL treats a user@localhost and a user@% as different grants entirely. A Can't connect response points to MariaDB itself: check systemctl status mariadb for a failed or inactive state, and check journalctl -u mariadb for the reason, which is very often a disk-full condition or an out-of-memory kill on a small server under load. On a CloudStick server, PHP-FPM talks to your site over a Unix socket at /run/<sitename>.sock, but WordPress's connection to the database goes over the DB_HOST value in wp-config.php, almost always localhost via TCP or socket to MariaDB 10.6 — the two are unrelated failure paths, so a healthy PHP-FPM socket does not mean the database is reachable. If you would rather avoid the command line entirely, CloudStick can reset the MySQL root password directly from the dashboard on BASIC plan and above, which is useful when you have lost root access and need a fast way back in without SSH.
Repair a Corrupted Database
If the mysql command connects fine but WordPress still shows the error, or the error appears only on specific pages, a corrupted table is the likely cause — run mysqlcheck to find and repair it rather than restoring from backup as a first resort. Corruption usually follows an unclean server shutdown, a disk that filled up mid-write, or a forceful process kill during a large query.
For InnoDB tables — the default engine for WordPress since 5.5 — auto-repair mostly resolves index-level issues rather than deep page corruption; if mysqlcheck reports it cannot repair a table, the safer path is restoring that table from a known-good backup rather than forcing repair operations that can silently drop rows. This is where having automated, verified backups actually pays off: CloudStick's Backups feature captures full database and file backups on a schedule and lets you restore a single site without touching the rest of the server, so a corrupted wp_options or wp_posts table is a restore away rather than a multi-hour recovery project. Always take a fresh backup of the current, broken state before running any repair command — a bad repair is still recoverable if you kept a copy of what you started with.
Preventing It From Happening Again
Most repeat occurrences trace back to two habits: editing wp-config.php by hand without verifying the value against the actual database user, and running a memory-starved server that lets MariaDB get killed under load. Fix the first by always confirming credentials through a tool that reads the live database state rather than trusting a config file someone else edited — CloudStick's Visual Database Manager does exactly that, showing the real username and letting you rotate the password safely whenever a migration or handoff happens. Fix the second by monitoring memory headroom on the server so MariaDB is not the first process the kernel kills when RAM runs out.
As a quick recap: check wp-config.php against the actual database credentials first, since that alone resolves the majority of cases; test the connection directly with the mysql client to separate a credentials problem from a service outage; run mysqlcheck if the connection itself works but specific pages still fail; and take a fresh backup before any repair operation so you always have a way back. If the site still will not connect after all four checks, the next move is a full restore from a recent backup rather than continuing to debug a database that may be more damaged than mysqlcheck can detect.
