Database data is lost after 'docker compose down' due to PGDATA path mismatch

[SummerBreezeOps]

Describe the bug
Currently, in the default docker-compose.yml, the PostgreSQL volume is mounted to /var/lib/postgresql/data. However, the PostgreSQL image used in the project (or its specific version: postgres:18.1-alpine@sha256:4eb15de8e7b692c02427a2df278d18eb89422a534e428efb6d43c968250334d4) stores data in a different internal directory (e.g., /var/lib/postgresql/18/docker).
As a result, the persistent volume remains empty, while all database files are stored in the container's ephemeral writable layer. When docker compose down is executed, the container is removed, and all data is lost.

To Reproduce

1. Run docker compose up -d.
2. Complete the setup and add any data to DefectDojo.
3. Run docker compose down (without the -v flag).
4. Run docker compose up -d again.
5. All previously entered data is gone, and the database is re-initialized.

Expected behavior
Database records should persist between container restarts/removals because a volume is defined.

Technical Details
The output of SHOW data_directory; inside the postgres container shows:
data_directory: /var/lib/postgresql/18/docker (or similar non-standard path).
But the docker-compose.yml mounts the volume to:
/var/lib/postgresql/data.

Suggested Fix
Explicitly set the PGDATA environment variable in the postgres service to match the volume mount point:

  postgres:
    environment:
      PGDATA: /var/lib/postgresql/data
    volumes:
      - defectdojo_postgres:/var/lib/postgresql/data

[valentijnscholten]

Thanks for reporting this. Personally I'm a big fan of hitting CTRL-C many times to shutdown which doesn't expose this problem. PR raised and linked.