What Is the Default Postgres Password and How to Change It?

PostgreSQL, also known as Postgres, is one of the most popular and powerful open-source relational database management systems. A default username is set for administrative purposes when installing Postgres. However, many articles get this wrong there is not a universal default Postgres password across all installations. Whether a password exists and whether one was ever set depends on your installer, operating system, package defaults, and the rules in pg_hba.conf.

Short Answer: Does PostgreSQL Have a Default Password?

Usually, no. PostgreSQL commonly creates a default superuser named postgres, but there is not a universal default Postgres password across all installations.

That's the part many articles get wrong. The default PostgreSQL username is often postgres, but whether you need a password — and whether one was ever set — depends on your installer, operating system, package defaults, and the rules in pg_hba.conf.

If you came here looking for the exact answer to "does postgres have a default password," that's it: there usually isn't one default password you can rely on. In some environments, local logins use peer authentication and won't ask for a password at all. In others, the installer prompts you to create one during setup.

The default superuser is usually postgres

Most PostgreSQL packages create a built-in administrative role called postgres. That role is the PostgreSQL superuser in many default deployments, so people naturally assume the password must also be postgres. I've seen that assumption cause more confusion than almost anything else in beginner setups.

There is not always a universal default password

Some installers ask you to define a password during setup. Some Linux packages lean on local socket authentication instead. And some managed environments hide the whole thing behind their own control layer. So if you're searching for the default postgres password, the honest answer is that your installation may have no preset password at all.

Why the answer depends on your installation and auth settings

Password existence and password usage are separate issues. A role can have a password stored, but local access may still use peer authentication and ignore that password. That's why two servers running the same PostgreSQL version can behave very differently.

Default PostgreSQL Username vs Password

A lot of users mix these up, and fair enough — the terms are close enough to be misleading. In PostgreSQL, the username is really a role, and the password is just one possible way that role can authenticate.

What the postgres user is

The postgres role is usually the default PostgreSQL superuser account. It can create databases, manage roles, alter permissions, and change server-level objects. On Linux, there's often also an operating system user named postgres, and that overlap confuses people all the time.

When PostgreSQL asks for a password

PostgreSQL asks for a password when the connection rule in pg_hba.conf requires password-based authentication. If the rule says md5 or scram-sha-256, you'll be prompted. If the rule says peer for local socket connections, PostgreSQL may trust the matching operating system account instead.

Why some systems use local peer authentication instead

On Ubuntu and Debian especially, local administrative access often uses peer auth by default. That means if you are the OS-level postgres user, you can connect without typing a database password. It's convenient for admin work, but it also explains why "default postgres username and password" is the wrong mental model for many Linux installs.

How PostgreSQL Authentication Works

Here's the practical version: PostgreSQL checks pg_hba.conf first, matches your connection type and source, and then decides what auth method to enforce. Your role password matters only if the selected method actually uses passwords.

So what does this actually mean? You can set a password for postgres and still get a peer authentication error. That's not contradictory. It just means the auth rule never got far enough to use the password.

peer authentication

peer is common on local Unix socket connections. PostgreSQL asks the operating system who you are, and if your OS username maps to the requested database role, access is granted. No password prompt.

This is why commands like the one below often work on Linux:

sudo -u postgres psql

md5 authentication

md5 is the older password-based method you'll still see in a lot of tutorials and legacy setups. It requires a role password and performs a hashed password exchange. It still exists, but for newer deployments I'd avoid building fresh systems around it unless you've got compatibility constraints.

scram-sha-256 authentication

scram-sha-256 is the better modern choice where supported. It improves password handling and is generally preferred over MD5 for new PostgreSQL installations. If you're updating auth rules anyway, this is usually the direction to move.

trust authentication and why it is risky

trust means PostgreSQL accepts the connection without asking for a password. That's dangerous. Full stop.

You might use it briefly for tightly controlled local recovery, but only on local connections, only during a short maintenance window, and only if you revert it immediately. Never widen remote access just to reset a password. I've seen that turn into a very bad day.

Role password vs pg_hba.conf authentication method

This distinction matters. A PostgreSQL role password is stored for the role. The pg_hba.conf file decides whether PostgreSQL will use that password for a given connection attempt. That's the key to understanding peer authentication failed, password authentication failed, and similar login issues.

How to Change the postgres Password Safely

If you can already access PostgreSQL as an admin, changing the password is easy. And the good news is this part usually doesn't require a restart, because you're changing the role credential, not the server process itself.

Change password from psql

On many Linux systems, start by opening a local psql session as the OS-level postgres user:

sudo -u postgres psql

Then set a new password:

ALTER USER postgres WITH PASSWORD 'new_strong_password';

This is the most direct answer for users searching how to change postgres password in Linux.

Change password with SQL

ALTER USER and ALTER ROLE are effectively equivalent for this job in PostgreSQL. If you prefer the more role-centric syntax:

ALTER ROLE postgres WITH PASSWORD 'new_strong_password';

Change password with \password

If you'd rather not place the password directly in your SQL history, use the interactive command inside psql:

\password postgres

PostgreSQL will prompt you to enter the new secret twice. I personally prefer this method on shared shells because it keeps the plaintext out of command recall.

Restart requirements and when they apply

Changing only the role password usually does not require a PostgreSQL restart. But if you also edit pg_hba.conf to switch auth methods, you'll need a config reload or, in some cases, a restart depending on your environment. If you're looking for service commands, see how to restart PostgreSQL on Linux and your platform-specific service manager docs.

How to Reset the postgres Password If You Forgot It

Now here's the thing: resetting a forgotten postgres password is where a lot of bad tutorials go off the rails. They tell you to switch everything to trust and move on. Don't do that casually.

The safer approach is local-only recovery, a backup of pg_hba.conf, the smallest possible temporary change, then immediate rollback.

Before you begin: back up pg_hba.conf

Make a backup first. Always.

cp /path/to/pg_hba.conf /path/to/pg_hba.conf.bak

The exact path depends on your installation/package manager, which I'll cover in the OS section below.

Temporary local recovery steps

For recovery, modify only the local rule needed to let you connect on the server itself. Do not add broad host all all 0.0.0.0/0 trust entries. That's the sort of mistake people remember for years.

A temporary example for local-only recovery may look like this:

local all postgres trust

Or, depending on your existing layout, a local line for all users on the Unix socket. Keep it narrow. Keep it temporary.

Set a new password

After changing the local rule, reload PostgreSQL if needed, connect locally, and set the password:

psql -U postgres

ALTER USER postgres WITH PASSWORD 'new_strong_password';

Revert the auth configuration immediately after reset

As soon as the password is changed, put the original secure auth rule back. Usually that means restoring peer, md5, or preferably scram-sha-256 depending on your setup. Don't leave trust behind "just for now." Those temporary shortcuts have a habit of becoming permanent.

Reload or restart PostgreSQL

After restoring the auth file, reload or restart the service so PostgreSQL reads the updated rules. If you edited only role data, no restart is needed. If you edited pg_hba.conf, a reload is usually enough.

PostgreSQL Password Change Commands by Environment

Package layouts vary. Service names vary too. That's normal. The commands below are the patterns you'll usually need, but double-check your exact installation.

Ubuntu and Debian

These systems often use peer authentication for local admin access, and the config commonly lives under a versioned directory such as:

/etc/postgresql/15/main/pg_hba.conf

Typical commands:

sudo -u postgres psql
sudo systemctl reload postgresql
sudo systemctl restart postgresql

If you're still setting up the database stack, see install PostgreSQL on Ubuntu and a fuller PostgreSQL setup guide.

RHEL/CentOS/AlmaLinux/Rocky Linux

Common package installs place configs under PostgreSQL data directories or versioned library paths, often something like:

/var/lib/pgsql/data/pg_hba.conf
/var/lib/pgsql/15/data/pg_hba.conf

Typical service commands:

sudo -u postgres psql
sudo systemctl reload postgresql
sudo systemctl restart postgresql

Some vendor packages use service names like postgresql-15. Check with systemctl list-units | grep postgres if needed.

macOS with Homebrew

On Homebrew systems, PostgreSQL config locations depend on the installed formula version and architecture. You'll often inspect the data directory with:

brew info postgresql
psql postgres

Service control usually looks like:

brew services restart postgresql

Windows

Windows installers usually ask you to set the postgres password during setup, which is one reason Windows users more often expect a "default password" answer. The config file commonly lives in a data directory such as:

C:\Program Files\PostgreSQL\15\data\pg_hba.conf

Open an elevated command prompt or use the Services console to restart the PostgreSQL service after config changes. If you need the installation basics, a related guide would be how to install PostgreSQL on Windows.

Version note: commands vary by PostgreSQL version and packaging

PostgreSQL 15 on Ubuntu 22.04 won't look exactly like PostgreSQL 13 on Rocky Linux or a Homebrew install on Apple Silicon. Same database, different packaging decisions. So if a path isn't where you expect, that doesn't mean the method is wrong — it usually means your package manager chose a different layout.

How to Verify the New Password Works

This step gets skipped a lot, honestly. Then the admin logs out, comes back later, and discovers they never tested the actual password path.

Test with psql -U postgres -W

Run:

psql -U postgres -W

The -W flag forces a password prompt. If the login succeeds, your new postgres password works for password-based auth.

Confirm the server accepts password auth

If PostgreSQL doesn't prompt for a password, check pg_hba.conf. You may still be hitting a peer rule for local access. That doesn't mean the password change failed. It just means this connection path isn't using password authentication.

Check for login failures in logs

If login still fails, inspect PostgreSQL logs. You're looking for exact messages like password authentication failed or details about the selected auth method. Those log lines usually tell you more than the client command alone.

Common Errors When Changing a PostgreSQL Password

Troubleshooting is where search intent gets messy. People search one phrase, but the real problem is something else entirely. Here are the errors I see most often.

FATAL: Peer authentication failed for user "postgres"

Likely cause: your connection matched a peer rule, but your operating system user doesn't map to the postgres database role.

Fix: connect as the OS-level postgres user with sudo -u postgres psql, or adjust pg_hba.conf to use a password-based method for the connection you actually want. This is the classic fix-peer-authentication-failed case.

FATAL: password authentication failed for user "postgres"

Likely cause: wrong password, wrong auth expectation, or a stale credential in your client/app config.

Fix: reset the password, verify the selected pg_hba.conf rule, and test again with psql -U postgres -W. Also make sure your application didn't cache old database credentials.

role "root" does not exist

Likely cause: you ran psql without specifying a role, so PostgreSQL tried to connect using your current OS username — often root.

Fix: specify the user explicitly:

psql -U postgres

database "postgres" does not exist

Likely cause: uncommon, but it can happen if the default maintenance database was removed or if you're targeting the wrong database name.

Fix: connect to another existing database such as template1 or a known app database:

psql -U postgres -d template1

Security Best Practices After Changing the Password

Changing the password is not the finish line. It's the minimum. The real security win comes from what you do next.

Use a long unique password

Pick a long random secret — ideally generated by a password manager or vault. Don't reuse your SSH password, panel login, or anything a teammate might already know. That sounds obvious, but I've seen it in production more than once.

Prefer SCRAM over MD5 where supported

If your environment supports scram-sha-256, use it for new password-based auth. It's a stronger default than older MD5-based setups and worth the small extra effort.

Limit remote access

Keep PostgreSQL bound to trusted hosts only, and tighten network exposure with firewall rules. If the database doesn't need public reachability, don't give it one. Pair that with a guide to manage firewall rules for database servers and a broader server hardening checklist.

Rotate credentials and store them securely

Use environment variables, a secrets manager, or a vault — not plain-text passwords hardcoded in scripts. And rotate credentials on a schedule that makes sense for your risk profile. If you're hosting databases on internet-facing systems, I'd also look at secure VPS hosting for databases.

Avoid using the postgres superuser for applications

Your app should not connect as postgres. Create a dedicated user with only the permissions it needs. Least privilege isn't glamorous, but it prevents small mistakes from becoming giant ones.

How to Create a New PostgreSQL User With a Password

This is usually the better move for applications and day-to-day service accounts. Use the superuser for administration, not for routine app traffic.

Basic CREATE USER example

CREATE USER app_user WITH PASSWORD 'another_strong_password';

When to use CREATE ROLE ... LOGIN

If you want the more explicit form:

CREATE ROLE app_user WITH LOGIN PASSWORD 'another_strong_password';

That's especially useful when you're building a cleaner role hierarchy. For adjacent admin tasks, you may also want a PostgreSQL commands cheat sheet or a guide on how to create a PostgreSQL database.

Grant only the permissions needed

Don't make every new user a superuser. Grant access narrowly:

GRANT CONNECT ON DATABASE mydb TO app_user;
GRANT USAGE ON SCHEMA public TO app_user;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_user;

If you're coming from a broader database comparison angle, these permission models are one reason people ask about PostgreSQL vs MongoDB and what PostgreSQL is used for in the first place.

Conclusion

Whether you're securing a fresh PostgreSQL installation or recovering access to an existing database, understanding how authentication actually works is the key to getting it right. The postgres role is your default superuser, but there's no universal default password you can rely on — your installer, operating system, and pg_hba.conf rules all play a part in whether a password is even required.

Changing the password is straightforward once you're connected, but resetting a forgotten password demands caution. The safe path is always local-only recovery with a temporary auth change that gets reverted immediately. And once the password is updated, the real work begins: prefer SCRAM-SHA-256 over older MD5 authentication, limit remote access with strict firewall rules, rotate credentials regularly, and never use the postgres superuser for day-to-day application traffic.