"Error establishing a database connection" means WordPress loaded, read its configuration, and could not reach the database. The site is down completely, including the admin area, and the message is the same for half a dozen different causes.
Work through them in this order. The first two account for most cases.
First: did anything change?
If you just changed a database password, edited wp-config.php, moved the site, or restored a backup, the cause is almost certainly that change.
Changing a password on the database user without updating wp-config.php takes the site down immediately, and it is the most common self-inflicted version of this error. How to Manage Database Users and Privileges explains doing both together.
Check the four values in wp-config.php
Open the file and read them carefully:
define('DB_NAME', 'account_wpdb');
define('DB_USER', 'account_wpuser');
define('DB_PASSWORD', '...');
define('DB_HOST', 'localhost');
Three specific things to check.
The account prefix. On shared hosting the database and user names both carry it. wpdb and account_wpdb are different names, and the second is the real one.
The host. Almost always localhost. Putting your domain there attempts a network connection to a database that is not listening for one, which produces a timeout in place of a refusal.
Stray characters. A trailing space inside the quotes, a smart quote pasted from a document, or a missing semicolon will all fail in ways that look like a wrong password.
Is the user attached to the database?
The step that catches people after a restore, and it produces exactly this error.
A database and a user are separate objects, and a user has to be added to a database with privileges. A restore frequently brings the database back without that link.
In cPanel's MySQL Databases screen, check that your user is listed under the database. If not, add it with all privileges on that database and try again. Nothing else needs changing.
Verify the credentials independently
Rather than guessing, test them somewhere WordPress is not involved.
Log in to phpMyAdmin. If you can open the database there, the credentials and the database are fine and the problem is in the configuration file or the host value.
If phpMyAdmin also fails, the password or the user is genuinely wrong: reset the user's password in cPanel and paste the new one into wp-config.php at the same time. How to Manage MySQL Databases with phpMyAdmin deals with getting in.
Is the disk full?
A full account cannot write, and a database that cannot write temporary files refuses connections.
This is worth checking early because it produces several unrelated-looking faults at once (mail rejected, uploads failing, sessions broken) and none of the errors mention disk. How to Monitor Your Hosting Resources explains where to look.
Is the database server actually running?
If the credentials are right and phpMyAdmin also fails, the service itself may be down or refusing new connections because it hit its limit.
On shared hosting that is a support ticket, and it is worth saying you have already verified the credentials. That skips two replies. For what else to include, see How to Write a Support Request That Gets Solved Fast.
On a VPS, check whether the service is running and read its log. The usual cause on a small server is memory: the kernel killed the database because nothing else was available, which leaves the site failing exactly this way. For preventing it, see How to Configure Swap and Memory on a VPS.
When only the front end is broken
If the site shows the error but /wp-admin/ offers to repair the database, one or more tables are marked as crashed instead of the connection being wrong.
Enable repair by adding this to wp-config.php:
define('WP_ALLOW_REPAIR', true);
Visit /wp-admin/maint/repair.php, run the repair, then remove the line. While it is present, anyone can reach that page without logging in.
Take a database export first if you can. Repair is usually safe and it is not guaranteed to be.
After a migration specifically
Two extra causes appear when the site was just moved.
The database was imported into a database with a different name, or the user was created with a different prefix on the new account, so the values that were correct on the old server are wrong here.
And the table prefix in wp-config.php must match the tables that were actually imported. A site whose tables are wp_ and whose configuration says wp2_ connects successfully and finds nothing, which produces the installation screen rather than this error. A useful distinction when diagnosing. How to Move an Existing WordPress Site to AHosting goes into the sequence.
What the variations mean
The error with no other detail: work through the list above.
"Unknown database": the name is wrong, usually the missing prefix.
"Access denied for user". The password is wrong, or the user is not attached to that database.
The installation screen instead. The connection worked and the tables are not there. Wrong prefix, or an empty database.
Those four point at four different fixes, which is why reading the exact wording is faster than changing the password again.
Test the credentials outside the application
The error message is the same whether the password is wrong, the user does not exist, or the server is refusing connections, and one command separates them.
mysql -u dbuser -p -h localhost dbname -e "SELECT 1" mysql -u dbuser -p -h localhost -e "SHOW DATABASES"
A successful connection means the credentials are correct and the fault is in how the application is using them, which is usually a stray character in the configuration file or a file the application is not actually reading.
An access denied message names which user and host it refused, and that is the detail that identifies the problem. A user defined for one host connecting from another is refused with a message that reads exactly like a wrong password.
Check whether the server is refusing everyone
When several sites on the same machine fail together, the cause is the database rather than any one site.
systemctl is-active mysql mariadb 2>/dev/null mysql -e "SHOW STATUS LIKE 'Threads_connected'" 2>/dev/null mysql -e "SHOW VARIABLES LIKE 'max_connections'" 2>/dev/null df -h /var/lib/mysql 2>/dev/null | tail -1
Connections at the limit produce this error for every new request while existing ones continue, which is why the site fails for new visitors and works for whoever is already using it.
A full disk stops the database writing and it refuses connections rather than corrupting data. That is the case worth checking first, because it is common, it explains the symptom completely, and the fix is not in the site at all.