supabase
🐛 Local Postgres container fails to start unless `.temp/postgres-version` is pinned
Bug description
When using supabase start locally, if .temp/postgres-version is not manually set, the CLI pulls the latest Postgres image (currently v17.4.x). This causes the Postgres container to fail startup, with errors in WAL recovery and a missing 99-roles.sql file. Eventually the container is marked as unhealthy.
Logs
LOG: database system was interrupted; last known up at ...
LOG: redo starts at ...
LOG: invalid record length at ...: expected at least 24, got 0
psql: error: /docker-entrypoint-initdb.d/init-scripts/99-roles.sql: No such file or directory
Final CLI error:
supabase\_db\_<project> container is not ready: unhealthy
Steps to reproduce
- Create or clone a Supabase CLI project
- Run
supabase startwithout creating.temp/postgres-version - Observe that
supabase_db_*fails to start - See WAL recovery + init-script errors in logs
Expected behavior
Supabase CLI should default to a known stable Postgres version (e.g. 15.x) instead of latest, unless user explicitly opts into newer version.
Workaround
echo '17.4.1.010' > supabase/.temp/postgres-version
supabase stop
supabase start
This makes the container healthy and bypasses WAL/init errors.
Environment
- OS: Windows 11 + WSL2
- Supabase CLI: 1.202.0
- Docker: 24.0.6
- Supabase repo: https://github.com/ChenYujunjks/todolist_deploy
- Reported by: Bruce Chen (via ChatGPT assistance)
Suggestion
Supabase CLI should:
- Either pin a stable default Postgres version (like 15.x)
- Or provide a clear warning when pulling latest may cause incompatibilities
This seems to be an issue with local db volume. Did you try supabase stop --no-backup before supabase start?
closing as duplicate https://github.com/supabase/cli/issues/3639
This seems to be an issue with local db volume. Did you try
supabase stop --no-backupbefore supabase start?closing as duplicate #3639
I didn't. Last time I solved it by editing the echo '17.4.1.010' > supabase/.temp/postgres-version
But now is update supabase to 2.31.4 and it seems it no longer has this bug anymore