Skip to content
codecollab.pl
§ Blog error establishing a database connection

Error Establishing a Database Connection in WordPress - How to Fix It

The message looks alarming, but all it says is that the site engine cannot reach its database - and the data itself is almost always intact

Krystian Kacik 7 min read
Contents

The message looks alarming, but all it says is that the site engine cannot reach its database - and the data itself is almost always intact. WordPress has two halves: the files that build the site, and the database that holds the posts, products and orders. “Error establishing a database connection” means the first half cannot connect to the second. The database itself is usually sitting there untouched - it is only the bridge between them that has been cut.

Below we walk through the repair step by step, without needing to know any code. And if at some point you feel this is not your thing, there is a shortcut at the end.

What “error establishing a database connection” actually means

Every time someone opens your site, WordPress logs into the database: it supplies the database name, the user, the password and the database server address. If any one of those does not match, or the database server is not responding, you get this message instead of your site. That is a different case from a critical error, where the code in a plugin or theme falls over; here the code is healthy, it just has nothing to read from.

The most common causes, in order of likelihood:

  1. Wrong database credentials in wp-config.php - the classic after moving a site to different hosting, when the old details were left in the file
  2. A dead or overloaded database server at the host - the site worked this morning, it is down this afternoon, and you changed nothing
  3. Corrupted database tables - after a sudden server restart, for example, or an interrupted update
  4. Resource limits exhausted on cheap hosting - traffic grew, the plan stayed from launch day

Step 1 - look at /wp-admin

Open your site’s address with /wp-admin on the end. If instead of the login screen you see a different message from the one on the homepage - for example a suggestion that one of the database tables needs repairing - that is a valuable clue: the connection to the database exists, one table is simply damaged. In that case go straight to step 2. If you see the same connection error everywhere, start at step 3.

Step 2 - database repair mode

WordPress has a built-in mode for repairing damaged tables. You turn it on with a single line in wp-config.php (you will find it over FTP or in your hosting panel’s file manager, in the site’s root folder):

define( 'WP_ALLOW_REPAIR', true );

Once you have added that line, go to yourdomain.com/wp-admin/maint/repair.php and click to repair the database. WordPress will walk the tables and patch back together whatever it can.

Important: once the repair is done, remove that line from the file. The repair page requires no login - as long as the line sits in the file, anyone who knows the address can open it.

Step 3 - check the credentials in wp-config.php

In wp-config.php you will find four entries: the database name (DB_NAME), the user (DB_USER), the password (DB_PASSWORD) and the database server address (DB_HOST). Open your hosting panel, find the databases section and compare those values one by one against what the host is showing you.

This is the most common culprit after a site move: on the new hosting the database gets a different name, a different user and a different password, while the migrated file still holds the old details. Sometimes only DB_HOST differs - on one host it is localhost, on another it is a separate database server address that the panel lists in the database details.

What helps: before you change anything in wp-config.php, download a copy of that file to your computer. One typo and the site will not come back at all - with a copy you are back to square one in a minute. If you do not know the database password, hosting panels usually let you reset it; you then put the new password into the file as well.

Step 4 - when everything checks out, look at the hosting

Credentials correct, table repair changed nothing, and the error is still hanging there? Then the problem is almost certainly on the server side. Check your host’s status page (most have one), look for a service restart option in the panel, and send support a simple question: is the database server for my account running, and has my account exceeded its resource limits. On cheap shared hosting that is a more frequent scenario than people expect - and no change to your files will help, because the fault sits outside your site.

If the error comes and goes in waves, that also points at server overload rather than your configuration. A related failure from the same server-side shelf is the 500 error - it is diagnosed differently, but it sometimes has the same root cause: the server cannot keep up.

What not to do

  • Do not reinstall WordPress from scratch - it does not repair the database connection, and it is easy to overwrite a configuration that was one step from working
  • Do not edit wp-config.php without a copy of the file - the whole site depends on this file; make changes calmly, one at a time
  • Do not click around blind in phpMyAdmin - dropping or emptying a table is irreversible; if you are in there at all, read only, delete nothing

How not to be back here in a month

In this failure the stake is the database - so everything you have on the site: content, customers, orders. Which is why the first conclusion after the repair is this: your WordPress backup has to cover the database, not just the files, and it has to run by itself, at a rhythm matched to how often the site changes. The second conclusion: if the error kept coming back because of overloaded hosting, that is a signal the site has outgrown its plan.

You can also hand the whole thing to someone who watches it professionally as part of ongoing site care - with backups before every change and a response to failures before you even notice them.

FAQ

Is my data safe? Almost always yes - this error means a broken connection to the database, not the loss of its contents. The risk only appears with panicked moves: reinstalls and deleting tables in phpMyAdmin.

Why did the database error appear after moving the site? Because on the new hosting the database has a different name, user, password or server address, while the migrated wp-config.php still holds the old details. Comparing those four entries against the hosting panel solves most cases like this.

Can this error disappear on its own? It can - if the cause was a temporary overload of the database server. But that is not a reason to relax, it is a warning: at the next traffic peak it will be back.

What does a professional repair cost? A typical diagnosis plus repair is hours of work, not days. I give the specific figure after looking at the site - always in writing, before we start.


Would rather not watch over it every month yourself? I take sites and stores under ongoing care - backups, updates, monitoring, and priority when something breaks. Tell me what you run and I will send back scope and price.

§ Quote in 24h

Facing a similar problem and not sure where to start?

Describe the scope in two sentences or send a link. I tell you what to fix first, and you get a fixed bid in writing within 24 hours - no "from X" pricing.

Send your scope - quote in 24h