How to Change Your WordPress Database Password

This guide shows you how to change the password on the database that your WordPress site uses, safely, on your Noiz hosting. There is a catch that trips up almost everyone who tries it: the database password lives in two places that must always agree, and if you change one without the other your site stops loading and shows the message "Error establishing a database connection." This article explains where those two places are, walks you through changing the password in your hosting panel (or in phpMyAdmin), shows you how to update WordPress to match, and helps you recover if the site does go dark. It is written for Noiz clients who run their own WordPress site, using generic example names such as yourdomain.com that you replace with your own.

Two things are worth saying up front, because they save a lot of confusion. First, the database password is not the password you type to log in to WordPress; those are completely separate, and changing one never touches the other. If you are actually trying to regain access to wp-admin, you want a different guide, linked below. Second, the official documentation tells you what each database setting is, and the database software documents the command that changes a user password, but neither spells out the one thing that matters most here: that the two must be changed together, in quick succession, or the site breaks. That gap is exactly what this guide fills.

Last reviewed: 27 July 2026, against WordPress 7.0.2 (latest stable). This guide is written for Noiz hosting and is kept current against WordPress. It complements, and does not replace, the official WordPress and database documentation linked below.

Official Documentation Reference

• Editing wp-config.php (Advanced Administration Handbook): the full reference for the configuration file that holds your database credentials, including the database constants and every optional setting around them.
• Common WordPress errors (Advanced Administration Handbook): the official write-up of "Error establishing a database connection", which is the exact symptom of a password mismatch.
• How to install WordPress (Advanced Administration Handbook): describes the database name, user, password, and host that WordPress needs, and the possible values DB_HOST can take.
• ALTER USER (MySQL 8.4 Reference Manual): the canonical syntax for changing a database user's password from SQL, which is the command behind the phpMyAdmin route and applies equally to MariaDB.

Prerequisites

• Access to your Noiz hosting control panel. Noiz runs Plesk on the South African platform (neo.noiz.co.za), DirectAdmin on the Ireland platform, and ISPConfig. The panel is where you change the database user's password and where you reach phpMyAdmin.
• A way to edit wp-config.php: either an SFTP client with your SFTP credentials, or the File Manager built into your panel.
• A copy of wp-config.php saved to your own computer first, so you can put the original back instantly if anything goes wrong.
• A quiet moment. There is a short window during this change when your site cannot reach its database, so pick a low-traffic time and set aside a few uninterrupted minutes.
• If you are on a managed Noiz plan, you can skip the hands-on steps entirely and ask the Noiz support team to change the database password and update WordPress to match for you.

Two Passwords, One Match: What You Are Actually Changing

WordPress keeps all of its content, settings, and users in a database, and it connects to that database as a specific database user with a password. That single password exists in two separate places, and the whole of this task is about keeping them identical:

• On the database server. The user account (for example youracct_wpuser) has a password recorded against it inside MySQL or MariaDB. This is the real password, the one the database checks.
• Inside WordPress. Your site stores the same password in plain text in a file called wp-config.php, on the line define( 'DB_PASSWORD', '...' );. Every time a page loads, WordPress reads this value and offers it to the database to prove it is allowed to connect.

When both hold the same string, WordPress connects and your site works. The moment they differ, the database rejects the connection and WordPress cannot load a single page. That is why you can never change just one of them: changing the password on the database server without updating wp-config.php (or the reverse) is precisely what produces "Error establishing a database connection". The fix is not to change the password twice or reinstall anything; it is simply to make the two agree again.

This Is Not Your WordPress Login Password

It is easy to conflate the two passwords a WordPress site has, so it is worth being precise. The database password is what this guide changes: an infrastructure credential that only your server and wp-config.php ever see, and that no visitor or editor ever types. The WordPress login password is what you and your users type on the wp-login.php screen to reach the dashboard; it is stored, hashed, inside the database rather than in a file.

They are fully independent. Changing the database password does not log anyone out of WordPress and does not alter any user's login. Changing a WordPress login password does not touch the database credential and will not fix or cause a connection error. If your real goal is to get back into the admin area, changing the database password will not help you, and you should instead follow how to reset a WordPress admin password via phpMyAdmin. Come back here only when it is genuinely the database connection credential you need to rotate.

Why You Might Change the Database Password

There are a handful of legitimate reasons to rotate this credential, and knowing which one applies to you sets the urgency:

• After a security incident. If your site has been compromised, or you suspect the database credentials have leaked, changing this password is a core part of locking the attacker out, alongside the wider steps in the Noiz WordPress Security Checklist.
• When someone with access leaves. If a developer or agency who once held your database credentials no longer works with you, rotating the password ensures the old copy they hold stops working.
• It was weak or shared. A password that was set to something guessable during a rushed install, or that has been emailed around, is worth replacing with a strong, unique one.
• Routine hygiene. Some people rotate infrastructure credentials on a schedule as good practice. It is not required, but there is nothing wrong with it if done carefully.

Whichever applies, the mechanics below are identical. Choose a strong replacement, ideally a long random string from a password manager, and read the note on special characters in Step 3 before you generate it.

Before You Start: The One Rule That Prevents a Broken Site

Everything that goes wrong with this task comes from doing the two halves too far apart, so plan them as a single, quick operation:

• Have wp-config.php open and ready to edit before you change anything. The goal is to change the database password and update the file within seconds of each other, not to change the password and then wander off to find your SFTP client.
• Accept that there is a brief window. On a normal single-password setup there is no way to avoid a short moment where the site cannot connect, because for that instant the two copies disagree. Doing the steps back to back keeps that window down to seconds. A truly seamless rotation would need the database's dual-password feature, which shared hosting panels do not expose, so the practical answer is to pick a quiet time rather than to chase zero downtime.
• Keep a backup of wp-config.php. If you mistype the new password in the file, restoring your saved copy and re-doing the edit is faster than guessing.
• If the panel offers to generate the password, capture it immediately. Some panels show a generated password only once. Copy it the instant it appears, because you will need to paste that exact string into wp-config.php in Step 3.

Step 1: Find Your Current Database Details

Open wp-config.php from your site's root folder (the same folder that contains wp-admin and wp-content) and look near the top for the four database lines:

define( 'DB_NAME', 'youracct_wpsite' );
define( 'DB_USER', 'youracct_wpuser' );
define( 'DB_PASSWORD', 'the-current-password' );
define( 'DB_HOST', 'localhost' );

Note down the database name and, especially, the database user: that user is the account whose password you are about to change, and you need to change the password on the right one. On Noiz shared hosting the user name usually carries your account prefix, for example youracct_wpuser rather than plain wpuser, so copy the full name exactly as the file shows it. The DB_HOST value, almost always localhost, tells you the host part of the account, which matters for the SQL route in Step 2. Leave the file open; you will edit the DB_PASSWORD line in Step 3.

Step 2: Change the Password on the Database User

This is the first of the two halves. The reliable place to do it on Noiz shared hosting is your hosting panel, because the panel changes the password on the database user directly and with the right privileges. phpMyAdmin can do it too, but on shared platforms your phpMyAdmin login often lacks the permission to alter a user's password, so try the panel first.

In your hosting panel (recommended)

• Plesk (South African platform, neo.noiz.co.za): open Databases, find the database and expand its User Management, then select the database user. Use Change Password (or the password field on the user), enter your new password, and save.
• DirectAdmin (Ireland platform): open MySQL Management, select the database, then the database user, and use the option to modify or set a new password for that user. Enter it and save.
• ISPConfig: database users are managed separately from databases, so go to Sites, open Database Users, and click the user your site uses. Type the new password into the Database password field (or use the Generate Password link), confirm it in Repeat Password, and save the record.

Whichever panel you use, if there is a strength meter, aim for a long, strong password. As soon as you save, the database will only accept the new password, so your site is now effectively offline until you complete Step 3. Move straight on.

The phpMyAdmin or SQL alternative

If you prefer to work in phpMyAdmin, open it from your panel. Where your login has the privilege, the User accounts tab lists the database users; find the row for your user at its host, choose Edit privileges, and use the Change password section to set the new value. The equivalent single command, which you can run on the SQL tab, is:

ALTER USER 'youracct_wpuser'@'localhost' IDENTIFIED BY 'your-new-strong-password';

Two details decide whether this works. The host part ('localhost' above) must match how the user was actually created; if the account exists as youracct_wpuser@localhost and you target a different host, you change the wrong account, or none at all. Match it to your DB_HOST from Step 1. Second, on shared hosting your phpMyAdmin login frequently does not have the rights to alter another user, so this command may return an access-denied error, in which case the panel route above is the answer. The same ALTER USER statement works on both MySQL and MariaDB, so it does not matter which your site runs on.

Step 3: Update DB_PASSWORD in wp-config.php to Match

This is the second half, and it must follow immediately. In the wp-config.php you left open, change only the password on the DB_PASSWORD line to the exact string you just set on the database user:

define( 'DB_PASSWORD', 'your-new-strong-password' );

Leave DB_NAME, DB_USER, and DB_HOST untouched; only the password changed. Keep the single quotes around the value, and paste the new password exactly, with no stray spaces before or after it inside the quotes. Save the file, and if you edited a local copy over SFTP, upload it back to the server so the live file is the one you changed. The instant WordPress reads a DB_PASSWORD that matches the database again, the site comes back.

A gotcha worth knowing before you pick the password. The value sits inside single quotes in a PHP file, so a password that itself contains a single quote (') or a backslash (\) will break the file unless you escape those characters, and an unescaped one typically produces a blank white page or a syntax error rather than a clean message. The simplest way to avoid the whole problem is to choose a strong password made of letters, digits, and safe symbols that excludes the single quote and the backslash. Length and randomness give you the security; those two particular characters buy you nothing but trouble here.

Step 4: Verify the Site and Your Login

Do not assume it worked; confirm it. Visit https://yourdomain.com in a fresh browser tab (or a private window, to sidestep any cached copy) and check that the site loads normally rather than showing the connection error. If it loads, the two passwords match and the change is complete.

Then confirm the human side is unaffected: go to https://yourdomain.com/wp-admin and log in as usual. Your WordPress username and login password are unchanged by this task, so you should get straight in exactly as before; the general guide to logging in to the WordPress admin dashboard covers this if anything looks off. A site that loads on the front end and lets you log in to the back end is your proof that the rotation is done and nothing else was disturbed.

Troubleshooting

• Symptom: "Error establishing a database connection" after the change. The two passwords do not match. Re-open wp-config.php and compare the DB_PASSWORD value character for character against what you set on the database user. The usual culprits are a mistyped or partly-pasted password, an accidental space inside the quotes, or an edited local file that was never uploaded back to the server. Correct the file to match and the site returns.
• Symptom: the site is still down and you cannot tell which copy is wrong. Set the password on the database user again in your panel to a fresh known value, then paste that same value into DB_PASSWORD and save. Re-setting both ends to one string you are sure of removes the guesswork.
• Symptom: a blank white page or a PHP syntax error instead of the connection message. This points at the file itself, not the credential, and most often means the password contains a single quote or backslash that is breaking the PHP, or a quote around the value was deleted. Restore your backup of wp-config.php and redo the edit with a password that avoids those characters.
• Symptom: you changed the password but the wrong site, or another site, broke. More than one site or user can share a database user. Confirm from each site's DB_USER which sites rely on the user you changed, and update every one of their wp-config.php files to the new password.
• Symptom: phpMyAdmin refuses to change the password, or you cannot see a User accounts tab. On shared hosting your database login usually lacks that privilege by design. Use your hosting panel to change the password instead, or ask Noiz support.
• Symptom: the connection error briefly appeared and then cleared on its own after you finished. That is normal and expected: it was the short window between the two halves. As long as the site is stable now, no action is needed.

When to Ask Noiz Support

Changing a database password is quick once you understand it, but it is unforgiving of a half-finished edit, and the whole reason you are doing it, often a security scare, is a poor time to be wrestling with a downed site. If you are on a managed Noiz plan, the simplest path is to open a ticket and ask the Noiz support team to rotate the database password and update wp-config.php to match; support can do both ends in one motion and confirm the site is back before closing the ticket. If you are self-managing and the site will not come back after your change, contact the Noiz support team with your domain, which platform your account is on, and the exact error you see (a screenshot is ideal), and a technician can compare the two passwords, correct the mismatch, and rule out any deeper cause such as a database user that has lost its privileges.