chore(supabase): bump postgres to 17.6.1.150

[Carlos-Vera]

What this PR does

Bumps the db image from supabase/postgres:15.8.1.085 to 17.6.1.150. One line, nothing else.

Why

New deployments from this template currently start on Postgres 15, which reaches end of life in November 2027, while Supabase self-host has been shipping 17.x for a while. Anyone deploying today inherits a major version they will have to migrate off sooner than necessary.

The part that needs a decision

This is a major version bump and it is not backwards compatible for existing deployments. A PG15 data directory will not start under 17 — the container exits on startup with a version mismatch. Anyone who redeploys after this lands, on a stack with data, breaks until they migrate.

So this only makes sense if it ships with a warning. Options, in the order I'd pick them:

1. Merge it into the next dated branch rather than an existing one, so it reaches new deployments and not running ones.
2. Merge it here with a note in the template README about the migration.
3. Leave the template on 15 and close this — perfectly reasonable, and no hard feelings.

For anyone who does want to move an existing stack, the path is a dump before switching images:

docker compose exec db pg_dumpall -U postgres > backup.sql
# stop the stack, remove the db volume, switch the image, start db, then:
docker compose exec -T db psql -U postgres < backup.sql

pg_upgrade also works but needs both binaries available in the same container, which this image doesn't make easy.

Tested

Running 17.6.1.150 from this template on EasyPanel, together with #79, for ~22 hours. All 13 containers healthy. That was a fresh deployment, not an in-place upgrade — I have not tested the migration path above on a PG15 stack with data, which is exactly why I'd rather this went to new deployments only.

[Carlos-Vera]

Follow-up on the untested part: I have access to another deployment still on 15.8.1.085 with real data, so I'll run the migration there in the next few hours and report back here.

I'll post the exact steps that worked, how long the dump/restore took, and anything that broke along the way — so the migration note in this PR stops being theoretical and becomes something you can point people at.

If it turns out to be messy enough that it can't be summarised in a few lines, that's an argument for option 1 (new dated branch only), and I'll say so.

[Carlos-Vera]

Reporting back on the migration I said I'd run.

I ran the in-place upgrade on a real EasyPanel Supabase deployment, 15.8.1.085 → 17.6.1.150: 17.6 healthy, all containers up, data intact. A few things turned out differently than this PR's body assumes, so here's the full picture rather than a summary.

What the deployment actually was. Honest caveat: it turned out to be a base Supabase install — the app schema wasn't deployed there yet, so public was empty. What got preserved was the whole Supabase infrastructure (auth, storage, realtime, vault + its roles and config), not a heavy business schema. So to test application-data preservation properly I ran the same upgrade locally against a stack replicating the EasyPanel layout (project-scoped container naming, no container_name, bind-mounted data dir) with a multi-tenant schema + RLS + seeded rows — every table's md5 byte-identical before and after, RLS suite green, and vault still decrypting a secret I planted beforehand.

in-place is more viable than I wrote here. The supabase/postgres image already ships Supabase's own initiate.sh/complete.sh; you run them from a one-off container against the stopped data dir. pg_upgrade itself was a few seconds; wall-clock is almost all image pulls + the ~1.2 GB tarball build the first time. I've put the tooling (autodetects the EasyPanel layout, --conversion-only so EasyPanel keeps owning start/stop, keeps a rollback copy) + a runbook in a separate PR so this one stays the one-line bump: #81.

What broke along the way:

• The db-config volume persists across the upgrade and can carry a PG15 setting 17 rejects (supautils.conf contains errors). Didn't trigger on 15.8.1.085 → 17.6.1.150, but I reproduced it by injecting a removed GUC. Fix regenerates db-config from the 17 image, preserving pgsodium_root.key — miss that and vault dies with invalid secret key.
• EasyPanel re-clones the template on every deploy, so the bump only sticks if it's in the pulled branch (the reclone did preserve volumes/db/data).
• After --conversion-only the service stays stopped; you Start it manually. Expected, and safer.
• Minor: the repo URL needs the explicit https:// scheme or EasyPanel reports "cannot access repository".

The bit I keep coming back to — the non-technical user. Whoever runs Supabase through EasyPanel mostly picked it to avoid a terminal, and this path still needs SSH (or the service web console) + running a script. So my honest lean: ship 17 on a new dated branch (option 1) so running stacks don't break on a redeploy they didn't ask for, and keep this tooling as the escape hatch for whoever actually needs to move an existing stack. Fuller reasoning in #81. Happy to go either way — it's your template.