postgresql 18 is asking for a different directory

[grpwise]

Adjust you yaml file to (see volume path)

postgres:
image: pgautoupgrade/pgautoupgrade:latest
env_file: /opt/redash/env
volumes:
- /opt/redash/postgres-data:/var/lib/postgresql/18/docker/

[ahmgithubahm]

I went with:

volumes:
- /opt/redash/postgres-data:/var/lib/postgresql

and this worked fine for me. The upgrade process at startup moved the data itself inside the volume so I now see 18/docker in there.

[snickerjp]

I've created PR #87 to address this issue by temporarily fixing the PostgreSQL version to v17.

While this repository is primarily used for new Redash installations (rather than upgrades), PostgreSQL 18 introduced some changes that may affect compatibility. As a precautionary measure, I've pinned the version to v17 to ensure stability while we monitor PostgreSQL 18's maturity and adoption.

This change:

• Uses pgautoupgrade/pgautoupgrade:17-alpine instead of latest
• Prevents potential issues with PostgreSQL 18's directory structure changes
• Maintains a stable setup experience for new installations
• Allows time to evaluate PostgreSQL 18's stability in production environments

Once PostgreSQL 18 proves stable and any compatibility issues are resolved, we can consider updating to v18 for new installations.

[snickerjp]

@grpwise

Thank you for the suggestion. We've merged an alternative fix with a slightly different approach.

As explained in the pull request, we are intentionally pinning the Postgres version to v17 to prevent unexpected automatic upgrades. Could you please pull the latest changes and let us know if this resolves the issue for you?

[grpwise]

In my tries before starting this thread I was successful i.e with "image: postgres:15".

[snickerjp]

@grpwise Thank you for the additional information!

Yes, using postgres:15 would definitely work and avoid the PostgreSQL 18 directory path issues entirely. That's a good alternative approach.

Our fix with pgautoupgrade/pgautoupgrade:17-alpine provides automatic upgrade capabilities while staying on a stable version, but your solution with postgres:15 is also perfectly valid for users who prefer a more traditional PostgreSQL setup without the auto-upgrade functionality.

Both approaches solve the original issue - the key is avoiding the unexpected jump to PostgreSQL 18 that was causing the directory path problems.

Thanks for sharing your successful configuration!