“Error establishing a database connection” means WordPress could not use the database connection required to complete the request. It does not, by itself, prove that your posts, orders, or customer accounts have been deleted.
To fix the error, preserve the current site, identify what changed, and compare the configured database connection with the hosting provider’s actual settings. If those settings are correct, investigate database-service availability, permissions, network access, connection limits, and specific evidence of damaged tables. Use repair or restoration only when the evidence supports that action.
This guide helps a business owner choose the right path and give hosting support a useful report. It also explains why changing passwords, repairing tables, and restoring an old backup are different operations with different risks.
Start with five observations
Before editing configuration, record these facts:
- When did the message first appear, and in which time zone?
- Is it constant or intermittent?
- Does it affect the dashboard, public pages, or only certain requests?
- Did hosting, credentials, configuration, code, or traffic change recently?
- Does the host report a database incident or account limit?
A site that failed immediately after a migration needs a different first comparison from a site that fails briefly every afternoon. A dashboard error while the homepage appears normal may mean the homepage is cached. It does not necessarily mean the dashboard uses a different database.
Capture the exact message. A database connection error differs from a PHP critical error, a firewall denial, or an HTTP gateway timeout. They can occur together, but a tutorial for one does not automatically resolve another.
If several sites on the same hosting account fail at once, tell the host. Shared timing can be useful evidence of an infrastructure or account issue. Do not start changing every site’s password merely because the visible message mentions a database.
What WordPress needs from the database
WordPress uses database records for content, settings, users, and many application functions. Plugins can add their own tables and records. WooCommerce, membership, booking, and form systems may store business data there as well.
The connection requires a reachable database service and a valid combination of database name, user, password, and host information. The database account also needs appropriate access to the intended database. Depending on the hosting architecture, network rules, sockets, ports, or encrypted connection settings may also matter.
The WordPress common-errors documentation identifies configuration and hosting problems as possible connection-error causes. Treat the message as a starting point for investigation rather than an instruction to run every repair listed online.
A database can be intact while its service is temporarily unavailable. The credentials can be correct while the account lacks access. A password reset can be successful in the hosting panel while WordPress still holds the old password. Distinguishing these states is the central task.
Preserve the current state before making changes
Confirm the most recent usable backup and preserve a current snapshot where possible. Include files and database, and record whether the backup completed before or after the first failure.
A backup created during an outage may still preserve useful current records, but its completion status and consistency need review. If the database is inaccessible, a file backup alone is not a complete current site backup. Ask the host whether an infrastructure snapshot or database backup is available.
The WordPress database-backup guide explains database preservation. The file-backup guide covers the separate application files and uploads. A post export is not equivalent to either complete recovery set.
Keep the last known good backup intact. Do not overwrite it with a new archive simply labeled “latest.” Record the recovery point, time zone, storage destination, and any encryption key or access dependency needed to restore it.
Think about recent business activity
A store or booking site can collect important data between backup time and failure time. External payment services may also record activity that the local application did not finish processing.
Before any database restore, identify that gap. Preserve current orders, leads, uploads, user registrations, and external records where possible. A list export can help reconciliation, but it may omit relationships and metadata required for a full application restore.
Do not assume that replacing the database with yesterday’s copy reverses payments, shipments, or emails. Those systems maintain their own state. The repair plan must account for them separately.
Choose the path that matches the evidence
| Situation | First useful check | Avoid as a first guess |
|---|---|---|
| Error began after migration | Actual destination database settings and imported data | Reusing the old host name automatically |
| Error began after password change | Account mapping and application credential update | Repeated uncoordinated resets |
| Many sites fail together | Host incident and database-service status | Editing every site’s configuration |
| Error appears during busy periods | Connection counts, slow work, and resource evidence | Raising limits without diagnosis |
| Host reports a specific damaged table | Backup and engine-appropriate investigation | Repairing every table blindly |
| Cached pages work but dynamic requests fail | Origin application and database path | Assuming the database is healthy |
If the starting point is unclear, gather one matching server or database error before making a broad change. The underlying error often distinguishes authentication failure from an unreachable service or exhausted connections.
Check the database settings without exposing secrets
On many self-hosted WordPress installations, connection constants appear in wp-config.php. Managed or customized environments may inject settings through environment variables or deployment tooling instead. Determine the actual source before editing a file that may not control the running application.
The WordPress configuration reference documents the standard settings. Compare each value privately with the hosting provider’s confirmed values:
- Database name: the exact database assigned to this site.
- Database user: the account WordPress should use.
- Database password: the current credential for that account.
- Database host: the provider’s endpoint, including supported port or socket details where applicable.
Do not paste these values into public forums, screenshots, or chat transcripts. A support provider can usually verify the mapping through its authorized panel without needing you to publish the password.
Verify the correct installation and account
A hosting account may contain staging copies, old migrations, and several databases. Confirm the document root and configuration source for the affected domain. Editing a backup copy of wp-config.php will not change the live application.
Database names and users can include provider-added prefixes. Similar names are easy to confuse. Check the assigned database and user relationship in the hosting panel rather than relying on memory.
If a deployment system generates configuration, a manual edit may be overwritten at the next release. Use the supported configuration process and record the change. Otherwise, the site can recover briefly and fail again when automation restores the old value.
Do not assume DB_HOST should be localhost
Some hosts run the database locally; others use a separate hostname, private endpoint, port, or socket. localhost and a network address can select different connection paths in some environments.
Use the provider’s documented value. A host name copied from the previous server may be unreachable or may point to the wrong database after migration. A hostname that resolves publicly may still be blocked from the application server’s private network.
The MySQL connection-troubleshooting documentation describes service, transport, and connection-path considerations. Your actual database may be MariaDB or a managed compatible service, so confirm the platform before applying product-specific commands.
Preserve PHP syntax when editing configuration
Back up the file and make the smallest change. Quotation marks, escaping, and statement syntax matter. A correct credential entered into invalid PHP can replace a database error with a fatal application error.
Do not add duplicate definitions below existing values and assume the new ones take effect. Locate the authoritative setting. If the password contains characters that need special treatment in the chosen configuration format, have a qualified administrator enter and validate it securely.
After saving, verify that the file remains protected and that no editor backup containing credentials is publicly accessible. Remove temporary copies from the web directory. Keep the protected recovery copy in the approved backup location.
Check user access and password changes as one operation
A database account can exist without the permissions needed for the intended database. Ask the host to verify the account-to-database mapping and the privileges appropriate to the application.
Do not use a database root account as a shortcut. The application should have the scoped access its deployment requires, and hosting administrators should handle broader infrastructure privileges.
If a reset is necessary, coordinate the database-side change and the WordPress configuration update. Identify every authorized application that uses the account before changing it. Shared credentials can affect staging, reporting, or another site, which is one reason separate scoped accounts are preferable.
Record the time of the reset without recording the secret itself. Retest through the application after the update. A successful hosting-panel login is not proof that WordPress now uses the correct account or transport path.
If the credentials changed without an authorized reason, preserve evidence and investigate access security. Recovery should include understanding the unexpected change rather than simply resetting the password and ignoring its origin.
Ask the host to verify database-service availability
When configuration is correct, ask whether the database service is running, healthy, and reachable from the application environment. A control panel can remain available while its database service has problems.
Give support a recent failed request time and the affected installation. Ask for the underlying database or application error, not just a statement that the server is online. Useful distinctions include connection refused, authentication denied, an unavailable socket, or exhausted connections.
For managed databases, ask whether there was a failover, endpoint change, maintenance event, or network-policy change. Do not attempt to restart infrastructure you do not own or understand.
A service restart can restore availability temporarily while leaving the cause unresolved. If the issue recurs, request evidence about memory pressure, disk capacity, connection behavior, and database logs around the failure.
Storage and account limits
A full disk, exhausted quota, or service-level account limit can interrupt normal database operations. The host should distinguish application storage from database storage and explain which limit was reached.
Do not delete database files directly through the file manager. Database storage is managed by the database engine, and arbitrary deletion can cause unrecoverable damage. Similarly, deleting tables because their names look unfamiliar can remove plugin or business records.
If cleanup is needed, preserve a backup and identify supported application-level retention controls. Large logs or temporary exports may be safe candidates after review, while order history and user records require a deliberate retention decision.
Investigate intermittent failures and connection limits
If the site works again without a configuration change, that does not prove the problem was imaginary. Intermittent failures can follow traffic bursts, slow requests, background jobs, or resource contention.
Record a pattern: affected times, duration, URLs, traffic changes, imports, backups, and scheduled integrations. Compare timestamps with the host’s database and application metrics. Keep time zones consistent across systems.
The MySQL too-many-connections documentation explains a specific connection-exhaustion condition. An actual matching error is stronger evidence than a general assumption that more visitors caused the outage.
Ask what held connections open and whether slow queries or application work increased their duration. Raising a connection limit without enough memory or capacity can create a different failure. A host or database specialist should evaluate the full resource picture.
Background work can compete with customer requests
Product imports, reporting jobs, backups, search indexing, and bulk email integrations can create expensive work. If failures coincide with one job, test its schedule and batch size through the supported controls.
Do not disable every scheduled task indefinitely. Scheduled work may handle renewals, inventory synchronization, or backups. Identify the owner and purpose of the specific job before changing it.
The WordPress Cron handbook provides background on scheduled execution. A host may use a system scheduler, and plugins may use additional queues. Record the actual arrangement rather than assuming every task is controlled by a single WordPress setting.
After adjusting a job, verify both sides of the outcome: customer requests should remain available, and the job should still complete its intended work. Moving a failure out of business hours is not a full repair if inventory never updates afterward.
Cache can hide the timing of an outage
A page cache may continue serving a homepage while new dynamic requests fail. An object cache can also influence the data path. Record the layers involved and use the host’s approved cache-bypass procedure for diagnosis.
Do not purge every cache as the automatic first step during a database outage. A large purge can move more traffic to an unhealthy origin. Ask the host whether targeted invalidation or temporary traffic controls are appropriate.
Once the database is healthy, verify the real application and the cached public experience. Recovery should not leave a stale error response circulating after the origin is restored.
Treat corruption as a specific diagnosis
A connection error is not proof of database corruption. Repair tools address certain table problems; they do not fix a wrong password, unreachable service, or denied account.
Look for a host or database error identifying a particular table or integrity problem. Record the database engine and storage engine involved. Repair procedures differ, and some operations are unsupported for particular engines.
Before any repair, preserve a suitable backup or snapshot and understand whether the action can change data, lock tables, or interrupt writes. A specialist should choose the method for the actual platform and symptoms.
Use WordPress repair mode only when justified
WordPress documents an optional repair facility enabled through WP_ALLOW_REPAIR. The configuration documentation warns that the repair interface does not require a logged-in user while enabled. That makes temporary access control and prompt removal of the setting important.
Do not leave repair mode enabled as a maintenance feature. If a qualified administrator uses it for an appropriate problem, follow the official procedure, record the result, and disable access immediately afterward.
Do not run repeated repairs after an unsuccessful result without reviewing the underlying database logs. An engine-level problem, damaged storage, or missing table may require a different recovery method. Repeated writes can complicate preservation of the current state.
A missing table is not the same as a damaged table
After a migration, the application may point to the wrong database or table prefix. The intended data can exist elsewhere even though the current configuration cannot find it.
Compare the configured prefix and imported table set with the known source. Do not rename tables or change the prefix merely to make names look consistent. Plugins, multisite networks, and custom integrations may have additional relationships.
If an installer appears unexpectedly, stop before creating a new site over the intended destination. Confirm the database mapping and imported data first. A connection that succeeds against an empty database is not a successful recovery of the existing business website.
Follow a migration-specific path when the error began after a move
A migration changes several assumptions at once: files, database location, account permissions, URLs, runtime, and sometimes networking. Work through the connection layer before treating content URLs as the primary cause of a connection failure.
Confirm that the intended database was imported completely and that the import did not stop because of size or timeout limits. Check the destination account’s access and the configured host. Compare the destination web PHP environment with the application’s requirements.
The WordPress migration guide explains the broader movement of files and database. Its URL-change considerations matter after connection is restored; they do not replace authentication or service checks.
If the old and new sites can both accept transactions, decide which is authoritative during the move. DNS changes can send different visitors to different servers for a period. Avoid creating two diverging stores while testing the destination.
Verify imports without guessing from file size
A large SQL file is not proof of a complete import. Review the tool’s completion status and errors, then verify expected tables and representative business records through authorized tools.
Compressed archive size can differ substantially from the resulting database size. Do not use an exact size match as the only acceptance test. The useful question is whether the required data and relationships are present and readable.
Keep the source backup and import log protected. Database exports can contain user details, password hashes, private settings, and integration secrets. Remove temporary SQL files from public directories after the migration is verified.
Decide whether restoration is necessary
Choose restoration when evidence shows that the required data or application state cannot be recovered more narrowly, or when a reviewed recovery plan makes restoration the best path. Do not use it as the first universal answer to a connection message.
Identify the recovery point and the scope: files only, database only, or a coordinated full site. A file-only restore may preserve recent records but must be compatible with the current database. A database restore can replace current content, users, settings, and transactions.
Test the recovery set on a protected copy where practical. Confirm that it is readable, complete, and appropriate to the incident. A backup made after a destructive change may faithfully restore the damaged state.
For suspected compromise, an older backup may also contain the attacker-controlled change. Restoration should be part of a security investigation and access review, not a claim that the site is clean simply because it loads.
Reconcile WooCommerce and subscription activity
WooCommerce’s backup documentation is useful for planning recovery coverage. Its subscription restore guidance explains why a rollback can bring already processed scheduled work back into an earlier state.
Before enabling a restored store, compare local records with payment, fulfillment, and subscription systems. Identify orders or renewals processed during the recovery gap and prevent duplicate actions through the supported component-specific process.
Do not manually copy a few order rows into a restored database and assume the store is reconciled. Orders can depend on related addresses, metadata, items, inventory changes, customer records, and extension data. A developer should use an application-aware method and verify the result.
Verify the repair through the application
A successful database connection test is one checkpoint. The website still needs application-level verification.
Start with a public uncached page and an authenticated dashboard request. Confirm that the expected site content appears, not a fresh installation or old staging copy. Inspect a recent record created before the outage.
Then test a safe write through a relevant workflow: save a controlled draft, submit a test form, or perform an authorized commerce test. Remove or identify test data through normal application controls afterward.
Check media, account access, integrations, and scheduled work relevant to the incident. A page can read existing records successfully while writes fail because of permissions or storage limits.
Review the matching error logs after testing. Confirm that the original connection failure stopped and that no new error replaced it. Remove temporary diagnostic tools and any publicly accessible export or repair interface.
Define completion honestly
A useful completion note states what changed, why, and what was checked. If the host restarted the service but has not identified the cause, record that uncertainty and the monitoring needed.
Avoid claiming that every function was tested when only the homepage and dashboard were opened. Identify delayed or external actions that still need observation. A subscription renewal scheduled for next week is not verified by a page refresh today.
Keep the final configuration source and credential ownership clear. If a temporary password or broad access grant was used, replace it with the intended scoped arrangement before closing the incident.
Build a precise hosting-support request
Include the affected domain and environment, exact error, recent failed request time with time zone, whether the failure is intermittent, and any recent migration or credential change.
Ask support to verify:
- The database service’s availability from the application environment.
- The intended database name and account mapping.
- The applicable endpoint, transport, and network access.
- The underlying connection error at the supplied time.
- Storage, account, and connection limits.
- Evidence of a specific table or storage problem, if suspected.
- Any restart, failover, restore, or configuration change they perform.
Keep the request factual. “The site failed at 2:15 p.m. Eastern after the import completed” is more useful than “WordPress deleted my database.” Share secrets only through the provider’s approved secure mechanism if they are truly required.
If several providers are involved, identify who owns the application server, database service, DNS, and deployment configuration. A connection problem can sit between those responsibilities. One coordinator should preserve the timeline and prevent simultaneous contradictory changes.
Three illustrative diagnosis paths
These scenarios are examples of reasoning, not reports of client work.
A migration uses the old database endpoint
The destination files are present, but every dynamic request fails. The administrator checks the destination host’s assigned settings and finds that the application still references the previous environment’s endpoint.
After preserving configuration and updating the authoritative setting securely, the team verifies the expected imported content and a safe write. It then checks URLs and other migration details separately. No table repair is needed because the failure was at the connection layer.
An afternoon import coincides with intermittent failures
The site recovers between brief outages. Rather than resetting credentials, the owner records timestamps and asks the host to compare connection behavior with the product-import job.
A developer reviews the supported import configuration, workload, and hosting capacity. The chosen correction is tested for both website availability and successful import completion. The incident record distinguishes observed connection pressure from assumptions about ordinary visitor volume.
A table problem is confirmed by the host
The host identifies a specific integrity problem and preserves a current snapshot. A specialist chooses a platform-appropriate recovery method and checks whether a known-good backup is needed.
Before reopening the store, the team reconciles recent transactions and tests application reads and writes. The decision to repair or restore follows the evidence; it is not triggered solely by the public connection message.
Distinguish connection tests from application tests
A database administration panel, a command-line client, and WordPress may reach the database from different places. A successful login in the panel proves only that that route and account worked at that time. The web application can still fail because it uses another endpoint, different credentials, a different network policy, or a different runtime configuration.
Ask the host to test from the relevant application environment using its approved secure method. Do not upload a public script that prints connection details or credentials. A diagnostic script can become an information leak if forgotten, and a simplistic success message may still conceal the wrong database mapping.
An experienced administrator should keep diagnostic output minimal and remove the test immediately after use. Record the result, time, and connection context in the incident notes without retaining the password. If the test succeeds while WordPress fails, compare the authoritative application configuration and request context rather than concluding that the database is universally healthy.
Read error categories without overinterpreting them
An access-denied response suggests the service was reached but rejected the attempted identity or access conditions. A refused connection points toward a different path, such as service availability or the endpoint. A missing socket message may indicate that the client attempted a local transport that does not exist in that environment.
Those categories guide the next question; they do not automatically establish the final cause. For example, authentication can fail because the application uses the wrong account, because the account mapping changed, or because it reaches a different service than intended. Preserve the full sanitized context and let the responsible administrator compare it with the actual server configuration.
Do not turn an error number found in a forum into permission to run a broad reset command. Database engines, versions, hosting models, and account privileges differ. Use product-specific procedures only after confirming that they apply to the installed platform.
Keep network and encryption requirements intact
A managed database may require private networking or encrypted connections. If a move changes the application server, its source network or approved identity may also change. Ask the provider to confirm the supported path.
Do not disable required encryption or open the database to every internet address as a troubleshooting shortcut. A narrowly scoped authorized network change can be tested and documented. A broad permanent allowance creates exposure that is unrelated to whether WordPress can authenticate.
If certificates or connection settings are involved, use the provider’s supported configuration. Record expiration and renewal ownership where relevant. The objective is to restore the intended secure connection, not merely to obtain one successful connection by weakening unrelated controls.
Verify database identity after a successful reconnect
Once the connection works, confirm that WordPress is reading the intended production data. A staging database can have familiar branding and old content, which makes a wrong mapping easy to miss during a quick homepage check.
Inspect a recent harmless content change and a known recent business record through the normal interface. Compare the expected user list and relevant application settings. Avoid exposing customer data in screenshots used for sign-off.
For a multisite network or a customized shared-user arrangement, involve someone who understands the database layout. A connection to the right service with the wrong prefix or network context can produce misleading results. Do not normalize every installation to a default prefix because a tutorial uses one.
Check that the configuration source will survive the next deployment. If a temporary manual edit restored the connection, update the managed secret or deployment setting through the approved process and verify the next release does not revert it. Remove obsolete secret copies and access grants after the final configuration is in place.
Finally, compare the recovered site’s timeline with any actions taken while it was unavailable. Staff may have processed orders manually, customers may have retried forms, and integrations may have queued work. Clear those operational gaps deliberately. A database connection is a technical capability; recovery is complete when the business can trust the current records and the next action will not duplicate or discard work.
Reduce the chance of a repeat outage
Keep database credentials in the intended configuration system and document who can change them. Use separate appropriate accounts for environments where possible. Record the database endpoint and ownership without storing secrets in a shared article or ticket.
Maintain backups outside the sole failure point and test restoration periodically. Review storage growth and long-running jobs before account limits become emergencies. Ensure alerts reach someone who can act.
Coordinate migrations, password changes, and hosting maintenance. A short change record can prevent hours of guessing. After a material change, test a dynamic read and a safe write rather than relying only on cached availability.
Review obsolete integrations and abandoned jobs through a controlled maintenance process. Reducing unnecessary database work can help, but deleting unfamiliar tables is not a substitute for understanding the application.
Retain a short recovery record
Keep the final database endpoint description, configuration owner, backup identifier, and repair timeline in an operational record. Store credentials separately in the approved secret-management system. The record should explain what failed and which evidence supported the correction.
Include the next observation needed if the cause was intermittent. For example, name the import or backup cycle that should be watched and who will review it. An outage that stopped after a restart deserves follow-up when the underlying pressure remains unexplained.
Review the record after the next material hosting or application change. Confirm that recovery access still works and that backup instructions refer to the current platform. This small maintenance step helps a future administrator avoid rediscovering account mappings and configuration sources during another outage.
Frequently asked questions
Does this error mean my content is gone?
No. It means WordPress could not establish or use the required connection for the request. The data may still be intact. Configuration, service availability, permissions, and resource limits should be checked before concluding that data was lost.
Should I change the database password first?
Only when evidence supports an incorrect or compromised credential. Coordinate the database-side change with the application’s authoritative configuration and identify other users of the account. An uncoordinated reset can make a service problem harder to diagnose.
Why does the homepage work while wp-admin fails?
The homepage may be served from cache while the dashboard needs a live application and database request. Compare the origin and cache paths. A cached page is not a database health test.
Can a plugin cause a database connection problem?
A plugin’s workload or configuration can contribute to resource pressure or expose an environment issue. However, the visible message alone does not identify a plugin. Correlate the failure with logs, jobs, and a controlled reproduction before changing components.
Should I run database repair tools?
Use them only for a relevant diagnosed problem with a recovery plan and an understanding of the database engine. Repair tools do not fix wrong credentials or an unreachable service. Temporary WordPress repair access must be disabled after use.
Why did the error appear after migration?
The destination may use a different endpoint, account, password, transport, or permission mapping. The import may also be incomplete. Confirm those details and the intended table set before changing content URLs or attempting repairs.
Will a backup restore lose new orders?
A database restore can replace records created after the recovery point. External payments and fulfillment actions are not automatically reversed. Preserve the current state and plan application-aware reconciliation before restoring an active store.
When should I contact hosting support?
Contact the host promptly when the service state, endpoint, account mapping, logs, or resource limits are unclear. A precise request with timestamps and environment details helps support distinguish infrastructure from application configuration and avoids speculative file changes.
Get the connection back with a clear recovery plan
The fastest useful path is to identify the failed layer, preserve current records, and make the smallest supported correction. A successful repair includes both a working connection and the business function that depends on it.
Web Expert Solutions provides WordPress database, migration, and hosting troubleshooting. If the error persists or a restore could affect current orders and leads, share the timeline and available backup information so the investigation can protect recent data and verify the recovered application.
