Why does the service report an error after some time, indicating an incorrect database password, when I deployed Dify using Docker Compose? The version of Dify I used is 1.9.2General Discussion

[gongchangping]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

Content

Why does the service report an error after a period of time when I deploy DIY using Docker Compose, indicating that the database password is incorrect? The version of DIY I am using is 1.9.2
Did the expansion of the database container lead to incorrect passwords when the data volume increased to a certain extent using dify with me? This is just my speculation. Has anyone encountered such a situation? I should avoid this kind of problem from happening
The log error is as follows: [error] failed to initialize database, got error failed to connect to host=db user=postgres database=dify_plugin: failed SASL authentication (FATAL: password authentication failed for user "postgres" (SQLSTATE 28P01))

I have encountered the same problem before when I had not changed my password. I was worried about password leakage, so I changed the database password and the password in the configuration file according to the requirements. I have been using it normally. Today, this problem suddenly occurred again. I guarantee that I have not changed or operated on the database password. Why do I still encounter this problem of incorrect database password

[dosubot[bot]]

This is a common issue with Docker Compose deployments of Dify. The error failed SASL authentication (FATAL: password authentication failed for user "postgres") is caused by a credential mismatch between your .env configuration and what PostgreSQL actually has stored in its persistent volume — it's not related to data growth or container expansion.

Why this happens: PostgreSQL only reads the POSTGRES_PASSWORD environment variable during the first initialization of the data directory. If you changed the password in your .env file after the database volume was already created, the running database still uses the original password, causing authentication failures [1].

How to fix it:

1. Verify running credentials match your .env:

   docker exec <db_container> env | grep POSTGRES_PASSWORD

2. If they're out of sync, the cleanest fix is to reset the volume (⚠️ back up your data first):

   docker compose down
   rm -rf ./volumes/db/data
   docker compose up -d

   This forces PostgreSQL to reinitialize with whatever password is currently in your .env.

3. Alternative without data loss — connect to PostgreSQL directly and change the password to match your .env:

   docker exec -it <db_container> psql -U postgres
   ALTER USER postgres WITH PASSWORD 'your_new_password';

To prevent this in the future: Never change DB_PASSWORD in .env after initial deployment without also resetting the PostgreSQL volume or manually updating the password inside PostgreSQL first [1].

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[gongchangping]

But when I didn't change my password, it prompted me with a password error. What's the problem

[dosubot[bot]]

Even without manually changing your password, there are several scenarios that can cause this to happen spontaneously:

1. Dify version upgrade — If you upgraded Dify (e.g., pulled a new docker-compose.yaml or .env.example), the upgrade process may have introduced a different default password or hostname. In particular, versions after 1.10.1 changed the database hostname from db to db_postgres, which can cause connection issues [1].

2. Volume corruption from forced shutdowns — If your Docker host ran out of disk space, crashed, or the container was forcefully stopped, the PostgreSQL data directory can become corrupted. This can manifest as authentication errors rather than obvious corruption messages [2].

3. Disk space exhaustion — If the Docker volume ran out of space, PostgreSQL may fail to start correctly and report misleading authentication errors [3].

To diagnose your specific case, run:

# Check if the password in the running container matches your .env
docker exec <db_container> env | grep POSTGRES_PASSWORD

# Check disk space
docker exec <db_container> df -h /var/lib/postgresql/data

# Check PostgreSQL logs for more detail
docker logs <db_container> --tail 50

If the password shown by env matches your .env file and disk space is fine, the most likely cause is data directory corruption from an unclean shutdown. In that case, the volume reset approach (with a backup first) is the safest fix.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[gongchangping]

I need to back up the data in the database now. How can I ensure that all the data in the database is backed up without omission

[dosubot[bot]]

To ensure a complete backup without omission, the simplest and most reliable approach is to stop the containers and copy the entire ./volumes directory [1]:

docker compose down
cp -r ./volumes ./volumes.backup
cp .env .env.backup
cp docker-compose.yaml docker-compose.yaml.backup

This captures all Dify data stores in one operation:

• PostgreSQL (./volumes/db/data) — contains both the dify and dify_plugin databases [2]
• Redis (./volumes/redis/data) — cache and job queue
• Application storage (./volumes/app/storage) — user uploaded files
• Plugin storage (./volumes/plugin_daemon) — plugin data
• Vector database — location depends on your VECTOR_STORE setting (e.g., ./volumes/weaviate, ./volumes/qdrant, ./volumes/pgvector/data, etc.) [2]

Alternatively, if you want a portable PostgreSQL-specific backup without stopping everything, you can use pg_dumpall:

docker exec <db_container> pg_dumpall -U postgres > dify_full_db_backup.sql

This dumps all databases (including dify_plugin) and user/role information into a single SQL file.

Important: Stopping the containers first (docker compose down) before copying volumes ensures data consistency — copying while PostgreSQL is running can result in corrupted backups [1].

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.