WooCommerce Error Establishing a Database Connection: Fix It Fast

A WooCommerce error establishing a database connection almost always means one of two things: wrong credentials in wp-config.php, or a database server that is down or out of connections. Scope it first — whole site or only some requests — then confirm DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST before touching anything else.

WordPress documents the usual culprit plainly: incorrect information in wp-config.php, followed by host-side problems such as an exceeded database quota or server downtime, with a compromised site as the last thing to check (source). On a store, a third cause matters just as much — running out of connections under load — because a store cannot cache its way out of database traffic the way a content site can.

Fast diagnostic checklist

Work down the table. Rows are ordered by how often each cause is the real one.

The order a competent engineer works in

Resist editing wp-config.php first. Two questions come before any change, and each halves the search space.

1. Is it total or partial? Total — every URL, including /wp-admin — points at credentials or a dead service. Partial, where cached pages render but cart and checkout fail, points at saturation, because those pages are the ones that must hit the database.
2. Can anything reach MySQL right now? From the application server, run wp db check, which runs mysqlcheck against the credentials already in wp-config.php (source). If that connects, PHP's configuration is not the problem and you are looking at capacity. If it does not, you have a reachability or credentials problem.

Only then start changing things, one at a time, writing down what you changed. Restoring a backup before you know the cause turns a ten-minute outage into a data-loss decision.

Cause 1: wrong credentials in wp-config.php

This is the most common cause and the easiest to prove. Open wp-config.php and read the four constants: DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST. Then connect with exactly those values from the command line. If the client connects and WordPress does not, the difference is almost always DB_HOST — localhost resolves to a Unix socket while 127.0.0.1 forces TCP, and a managed database usually needs a hostname with an explicit port such as db.internal:3306.

Credentials break at predictable moments: a migration, a host move, a rotated password, or a deployment that overwrote the file from version control with staging values. If the values look right, WordPress suggests resetting the MySQL password manually and trying again (source). Check file permissions in the same pass — a wp-config.php PHP cannot read fails the same way as one with the wrong password.

Cause 2: the database server is down or out of connections

If credentials are right and nothing connects, the service is the problem. Check whether the process is running, whether it restarted recently, and whether it was killed for memory. Then check connections, because "out of connections" looks identical to "down" from PHP.

MySQL is explicit here: if clients encounter Too many connections errors, all available connections are in use by other clients, and the permitted number is controlled by the max_connections system variable. Usefully, mysqld actually permits max_connections + 1 connections, with the extra reserved for accounts holding the CONNECTION_ADMIN privilege — so an administrator can still connect and run SHOW PROCESSLIST to diagnose problems even when every normal slot is taken (source). That reserved connection is the one to use during an incident.

Three numbers tell you the story: SHOW VARIABLES LIKE 'max_connections' for the ceiling, SHOW STATUS LIKE 'Threads_connected' for right now, and SHOW STATUS LIKE 'Max_used_connections' for the high-water mark since restart. If the high-water mark equals the ceiling, you have found your outage.

Cause 3: host resource limits

Shared and entry-level plans enforce per-account caps on concurrent database connections, CPU seconds, and I/O. When you hit one, the symptom surfaces as a connection error even though nothing is technically broken. WordPress lists this directly: contact your host to check whether the database quota has been exceeded, causing a shutdown, or whether the server is down (source).

The tell is that errors arrive without a corresponding traffic spike, and the host's dashboard shows a limit reached rather than a resource exhausted. There is no configuration change on your side that raises someone else's cap. Either the plan changes or the store moves to isolated resources.

Cause 4: a traffic spike exhausting the pool

This is the one that takes stores down on launch days. Each PHP worker handling a request holds a database connection for the life of that request. Slow queries make requests longer, longer requests hold connections longer, and connections held longer mean fewer available for the next arrival. Past a threshold, the pool empties in seconds and every request — including checkout — returns a connection error.

The compounding factor is specific to commerce. WooCommerce's own guidance is that Cart, Checkout, and My Account must be excluded from caching, along with the WooCommerce session cookies (source). Those are exactly the pages that convert. A content site absorbs a spike at the edge; a store passes the revenue-bearing half of it straight to PHP and MySQL. Add background jobs, stock sync, and reporting queries running at the same moment and the ceiling arrives sooner than the traffic graph suggests.

Short-term: shed load and raise the ceiling. Longer-term: fix the queries holding connections, keep autoloaded options small, and put capacity in front of the problem rather than tuning around it.

Cause 5: corrupted tables

A different message — "One or more database tables are unavailable. The database may need to be repaired" — means the connection succeeded and a table did not. Run wp db check, then wp db repair, which runs mysqlcheck with repair against the credentials in wp-config.php (source). Without shell access, WordPress ships a repair script: add the WP_ALLOW_REPAIR define to wp-config.php and visit /wp-admin/maint/repair.php, then remove the define immediately, because the page is deliberately accessible without logging in (source).

Take a backup before repairing, and treat corruption as a symptom. Tables rarely corrupt on their own; unclean shutdowns, a full disk, or failing storage are the usual precursors, and repair without addressing those buys you days, not a fix.

Why this costs more on a store than on a blog

A blog serving this error loses pageviews. A store loses orders it will not recover, because a customer who sees a database error at checkout does not return an hour later. The damage compounds in three ways: sessions in flight are lost, the traffic you paid for that day converts at zero, and payment callbacks that arrive during the outage may find nothing to write to, leaving orders in an inconsistent state you have to reconcile by hand afterwards. That reconciliation is often longer work than the outage itself.

How to stop it recurring

Alert on connection headroom, not on the error. Track Threads_connected against max_connections and page someone at 70%, well before the ceiling. Put the slow query log on and read it weekly, since the queries that will exhaust the pool are visible long before they do. Watch disk on the database volume so a full log directory never becomes a corruption event. Test plugin updates on staging with production-shaped data, because query regressions arrive with updates, not with traffic. And keep restorable backups with a known recovery time, so restoring is a decision you have already rehearsed.

How Urumi handles this

Connection exhaustion is a failure that announces itself in the metrics minutes before customers see it, and almost nobody is watching the right number. That is the class of problem platform-level monitoring catches. On Urumi, the fully managed APM covers database connections, query latency, and background jobs alongside web requests, so a store approaching its ceiling raises an alert while checkout still works — and horizontal auto-scaling across multi-zone Google Cloud means capacity moves before the pool empties. In load testing with the edge cache disabled, the platform sustained a 236 ms median cart response and 321 ms median checkout, and took 7,861 orders in under two minutes. More on the managed WooCommerce platform page.

Frequently asked questions

How do I fix error establishing a database connection in WordPress?

Check DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST in wp-config.php first, then confirm those exact values connect from the command line. If they do, the database is reachable and you are looking at capacity or a corrupted table rather than configuration.

Why does my WooCommerce store show a database connection error only sometimes?

Intermittent errors almost always mean the connection pool is running out at peak, or your host's per-account limit is being hit. Compare Threads_connected and Max_used_connections to max_connections during an episode; if the high-water mark reaches the ceiling, that is the cause.

Can too many visitors cause a database connection error?

Yes. Every in-flight request holds a connection, and cart, checkout, and account pages cannot be cached, so a store passes far more of a traffic spike to the database than a content site does. Once all permitted connections are in use, new clients get an error.

Will repairing the database fix the error?

Only if the message names unavailable tables. Repair with wp db repair or the WP_ALLOW_REPAIR script fixes corruption, not bad credentials or an exhausted connection pool — and corruption itself is usually a symptom of an unclean shutdown or a full disk worth investigating.

If these errors cluster around launches and sales, the underlying issue is capacity planning — see how to scale WooCommerce for high traffic and how many PHP workers WooCommerce needs.

Last reviewed September 2026. Competitor details come from their public pages on the dates linked; check them before you buy.