Postgres Version in docker-compose.yml breaks everything

[Patrik Kernstock]

I've seen the latest change committed and merged in a735885 from #16, which is in my opinion a breaking-change and a bad decision:

-    image: postgres:12
+    image: postgres:latest # or 13

Based on the commit, the description was:

By switching to the latest or 13 version, the plausible_db container will no more complain
about the wrong postgres version and shut down. This resolved my error, when i 
implemented this docker-compose into my own docker-compose.

I don't understand the reasoning. Specially this commit introduces three negative problematic aspects:

1. When new major releases are published from postgres, this could introduce incompatibility with Plausible. Bleeding edge is not always the best choice.
2. When new major releases are published, this will cause incompatibility with existing database files, as no automated upgrade is performed.
3. An upgrade is always one-way, and should be planned and not automatically rolled out.

All three are breaking changes, rendering the whole setup unstable, unreliable and unpredictable.

I've just merged the suggested change into my config, and then Postgres did not want to start:

$ docker-compose logs -f plausible_db
Attaching to plausible_plausible_db_1
plausible_db_1         |
plausible_db_1         | PostgreSQL Database directory appears to contain a database; Skipping initialization
plausible_db_1         |
plausible_db_1         | 2020-12-05 16:27:42.359 UTC [1] FATAL:  database files are incompatible with server
plausible_db_1         | 2020-12-05 16:27:42.359 UTC [1] DETAIL:  The data directory was initialized by PostgreSQL version 12, which is not compatible with this version 13.1 (Debian 13.1-1.pgdg100+1).

tl;dr: Using postgres:latest is a terrible idea and makes the plausible stack unpredictable. It does seem introduce the issue the author seems wanted to fix actually? (Also, why was this commit even merged?)

[Patrik Kernstock]

Additionally to #21 this is now the second breaking-change within a few days which required more detailed troubleshooting and broke the whole plausible setup. Even the fact I appreciate all the work, it's a bit frustrating. (Aren't the commits tested by someone, like commits authors or so?)

[Uku Taht]

Thanks for the detailed report. Merging this was my bad. I agree that at least we should pin versions so to keep the stack predictable.

Clickhouse configuration was a weird case. It worked for the author and in my own testing but we didn't test a clean install which is where the problems appeared.

The repo should be in a good state now.

As for moving forward. I'm not sure how to deal with breaking changes like upgrading the Postgres version. Initially I built this repo as just a starting point or a template for your hosting configuration. It was not meant to be a source of truth or a packaged thing. But it seems like people are doing git pull and expecting things to keep working? For that we would need to properly version these hosting setups and provide update scripts to migrate data volumes.