CLI does not detect stale local Postgres container version before declarative schema sync

[ArcureDev]

Describe the bug
After upgrading Supabase CLI, the local Docker setup was still running an older Supabase Postgres image/container version.

The local environment was using:

17.6.1.106

But the updated Supabase CLI expected/started from:

17.6.1.134

After that upgrade, running supabase db schema declarative sync generated a migration containing:

DROP EXTENSION pg_graphql;

Applying the generated migration failed with:

ERROR: extension "pg_graphql" does not exist (SQLSTATE 42704)
At statement: 1
DROP EXTENSION pg_graphql

Running supabase db reset produced the same issue when applying that migration.

The root issue seems to be that Supabase CLI did not detect that the running local Docker Postgres container/image was still on an older version after the CLI upgrade. As a result, schema diff/sync was generated against an inconsistent local state.

To Reproduce
Steps to reproduce the behavior:

1. Create the local Postgres version override file:

supabase/.temp/postgres-version

with this content:

17.6.1.106

2. Start the local stack:

supabase start

3. Confirm Docker is running the older image:

docker ps --format "table {{.Names}}\t{{.Image}}"

Expected local DB image:

public.ecr.aws/supabase/postgres:17.6.1.106

4. Update supabase/.temp/postgres-version to the newer expected Postgres image version:

17.6.1.134

5. Modify one table definition under supabase/database/schemas/public/tables.
6. Run:

supabase db schema declarative sync

7. Inspect the generated migration file.
8. Notice that it contains:

DROP EXTENSION pg_graphql;

9. Run:

supabase db reset

10. The reset fails with:

ERROR: extension "pg_graphql" does not exist (SQLSTATE 42704)
At statement: 1
DROP EXTENSION pg_graphql

Expected behavior
Supabase CLI should detect when the currently running local Docker Postgres container/image version does not match the version expected by the installed CLI.

In this case, it should detect that the local container is still using 17.6.1.106 while the expected version is 17.6.1.134, and either:

• warn the user clearly before running schema sync/reset commands,
• automatically recreate or update the local container/image when appropriate,
• or fail with an actionable message explaining that the local Docker environment must be restarted/recreated.

supabase db schema declarative sync should not silently generate a migration from an inconsistent local Docker/Postgres version state.

Additional context
I was able to fix the issue locally by fully stopping and restarting Supabase:

supabase stop --all --no-backup
supabase start

This forced Supabase to run with the correct Docker Postgres version, 17.6.1.134.

Then I removed the previously generated migration file and reran:

supabase db schema declarative sync

The newly generated migration no longer contained:

DROP EXTENSION pg_graphql;

This suggests supabase db schema declarative sync generated the incorrect DROP EXTENSION statement because the local Docker Postgres container was stale and still running an older version.

The CLI should detect this version mismatch and guide the user to recreate/restart the local Docker environment before generating migrations.