chore: move the compose stack to postgres 18 (#10827)

* chore: move the compose stack to postgres 18

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ha6ovKdT9XRoj5FyVe7fEt

* fix: dump the whole cluster in the postgres 18 upgrade recipe

Windmill creates instance datatable, DuckLake and wm_fork_* databases in the
same cluster as windmill, so a single-database pg_dump followed by removing the
volume loses them silently. Dump the cluster with pg_dumpall instead, which also
carries the roles the RLS policies are granted to, with their passwords.

Also wait on the healthcheck before restoring, stop services generically rather
than by name, and ANALYZE after the restore.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ha6ovKdT9XRoj5FyVe7fEt

* fix: analyze every restored database and check the restore for errors

ANALYZE is per-database, so the sibling datatable/DuckLake/wm_fork_* databases the
recipe now restores were left with no planner statistics; vacuumdb --all covers
them. psql does not stop on error and the old volume is gone by that point, so
the restore needs an explicit grep rather than a trusted exit code.

Also note that logical replication slots are never dumped, so a Postgres trigger
reading a database in this cluster comes back disabled until it is re-saved.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ha6ovKdT9XRoj5FyVe7fEt

* fix: drop the bootstrapped windmill database before the restore

POSTGRES_DB creates an empty windmill database, so the dump's own CREATE DATABASE
for it fails and its objects load into the entrypoint's database instead, keeping
the new cluster's encoding and collation rather than the dumped ones. Sibling
databases are created by the dump and so were never affected. Dropping it first
makes the restore reproduce the source cluster exactly, and leaves one expected
error instead of two.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ha6ovKdT9XRoj5FyVe7fEt

* docs: move the postgres 18 upgrade runbook out of the compose file

A step-by-step runbook in a config file needed corrections in three consecutive
review rounds, which is the argument for keeping it somewhere it can be fixed
once. The comment keeps only the constraint a reader has to know before touching
the mount, plus a link.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ha6ovKdT9XRoj5FyVe7fEt

* docs: point the postgres 18 upgrade note at windmill.dev

GitHub gists are owned by user accounts, never organisations, so a gist is the
wrong home for the only migration instructions every self-hosted operator gets.
The procedure now lives in the self-host docs page instead.

Depends on windmill-labs/windmilldocs#1704 merging and deploying first.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ha6ovKdT9XRoj5FyVe7fEt

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

docker-compose.yml

@@ -8,15 +8,28 @@ x-logging: &default-logging
     compress: "true"
 
 services:
+  ## UPGRADING FROM POSTGRES 16: db_data holds a cluster 18 cannot read, so the
+  ## container exits with an explanatory error rather than coming up blank. Migrating
+  ## means dumping the WHOLE cluster (pg_dumpall), never just the windmill database:
+  ## Windmill keeps datatable, DuckLake and wm_fork_* databases beside it and grants
+  ## its RLS policies to cluster-level roles, and a single-database dump loses both
+  ## silently. Full procedure, and why 16 is still a valid choice until Nov 2028:
+  ## https://www.windmill.dev/docs/advanced/self_host#upgrade-postgresql-to-18
   db:
     deploy:
       # To use an external database, set replicas to 0 and set DATABASE_URL to the external database url in the .env file
       replicas: 1
-    image: postgres:16
+    image: postgres:18
     shm_size: 1g
     restart: unless-stopped
     volumes:
-      - db_data:/var/lib/postgresql/data
+      # From 18 on the official image keeps the cluster in a major-version
+      # subdirectory (/var/lib/postgresql/18/docker), so the mount has to be the
+      # parent directory: that is what lets pg_upgrade see an old and a new
+      # cluster inside a single mount point. Mounting the pre-18 .../data path
+      # instead makes the image exit rather than start, which is what turns a
+      # stale 16 cluster into a loud failure instead of an empty instance.
+      - db_data:/var/lib/postgresql
     expose:
       - 5432
     environment: