supabase db diff issue on v2.58.5

[baresi687]

Describe the bug
supabase db diff shows schema changes no matter what.

To Reproduce

1. Reset db locally
2. Create new test function in public schema
3. Generate new migration file with db diff
4. Run supabase db diff

Expected behavior
supabase db diff should return 'No schema changes found'.
Instead it shows the test function.

System information

• Version of OS: Ubuntu 24.04.3 LTS
• Version of CLI: v2.58.5
• Version of Docker: v28.3.3
• Versions of services:
  supabase/postgres | 15.8.1.085
  supabase/gotrue | v2.182.1
  postgrest/postgrest | v13.0.7
  supabase/realtime | v2.63.0
  supabase/storage-api | v1.29.0
  supabase/edge-runtime | v1.69.23
  supabase/studio | 2025.11.10-sha-5291fe3
  supabase/postgres-meta | v0.93.1
  supabase/logflare | 1.25.3
  supabase/supavisor | 2.7.4

Additional context
Tried rm -rf supabase/.temp/. No difference.
Tested v2.59.6 pre release, same issue.

CLI versions 2.54.11 and 2.53.6 do not have this issue.

[zahariaca]

I've also noticed this behaviour.
Functions always seem to appear in the diff

[Xyeut]

I've been experiencing this on my end as well, regardless if I have new changes or not my schema file always contains certain functions/types despite them already being pushed to production

[freemarmoset]

I was using 2.47.2 without any diff issues. Now that version appears incompatible with the the current supabase docker images. Upgrading to latest 2.62.10 breaks this again. This is not the first bug reported on the diff breaking. I wish the team would prioritize this higher. I know diffing has never been 100% but it's been probably 99%. Not having a somewhat reliable diff makes the process my team has been organized around for months (update declarative schema files and generate appropriate migrations using diff anf then reviewing) completely useless.

[jeanmaried]

Can confirm this is happening for me to on 2.65.5. Functions that are part of previous migrations keep showing up in new migrations and it's a painful process to go through and delete them one by one without accidentally removing a change that is actually needed.

[jeanmaried]

Another issue is that renaming a column generates a DROP and an ADD statement. If you aren't super carefull you will accidentally drop a column and all it's values instead of just renaming it.

I just changed many functions in my projects and at this point it's pretty much impossible to review the diff. Please fix this 🙏🏻

[ogmzh]

so this is still an issue on version 2.72.2. funny enough, we have 4 databases that we maintain, 3 of them sync perfectly fine but the 4th one keeps spitting out drop and create or replace views that are IDENTICAL to what the schema state is at, and i'm at my wits end..

[paulteriele]

I'm experiencing the same issue while diffing our declarative schema against our migrations. Versions of Supabase CLI higher than v2.53.6 (the latest I've tested with is v2.72.7) will repeatedly (endlessly) result in migration file (with the exact same contents) for all views and materialized views that joins one or more times.

This prevents us from upgrading our CLI forwards from v2.53.6.

To Reproduce

• Supabase v2.72.7 (or at least higher then v2.53.6, that version does still work)
• Declarative Schema including one or more views with one or more joins
• Matching migration file(s)
• run $ supabase db diff -f changes (multiple times)

System information

• MacOS v26.2 (25C56)
• Docker v4.57.0 (215387)
• supabase/postgres-meta:v0.95.2
• supabase/edge-runtime:v1.70.0
• supabase/storage-api:v1.33.5
• supabase/postgrest:v14.3
• supabase/realtime:v2.69.2
• supabase/mailpit:v1.22.3
• supabase/gotrue:v2.185.0
• supabase/kong:2.8.1
• supabase/vector:0.28.1-alpine
• supabase/logflare:1.28.0
• supabase/postgres:17.6.1.071

Result

This will repeatedly (endlessly) result in migration file (with the exact same contents) for all views and materialized views that joins one or more times.

Expected Behavior

• No schema changes (especially after having ran $ supabase db diff -f changes once)

Failed workarounds

• $ supabase db diff --use-pg-schema -f changes
  • WARNING: --use-pg-schema flag is experimental and may not include all entities, such as views and grants.
  • Keeps resulting in:
  • failed to generate plan: generating plan statements: generating migration statements: resolving table diff: generating alter statements for "public"."redacted": generating sql: altering base table: resolving check constraints sql: generating alter statements for validate_redacted: generating sql: check constraints that depend on UDFs: not implemented
• $ supabase db diff --use-pg-delta -f changes
  • Keeps resulting in postgres role changes and one specific function
• supabase db diff --use-pgadmin -f changes
  • Keeps resulting in:
  • ⢿ Diffing local database with current migrations... error running container: exit 1

Succesfull workaround

Downgrading Supabase CLI to v2.53.6

[conte91]

We (github.com/silverstream-ai) are also affected, with the same exact results as #4460 (comment). Downgrading the CLI is unfortunately not an option since the older version fails to link to our database, so we're stuck. It's a pity since declarative schemas are really a HUGE value for supabase imho!

[ktn1234]

Currently experiencing the same issue as #4460 (comment) as well for a client I am setting up DB migrations CI/CD pipeline for that depends on supabase db diff --linked --schema public CLI command.

The CLI command continues to output the same schema diffs even after you created a migration file and apply a migration for those changes. It doesn’t detect that the migration has already been applied currently.

[avaer]

I've been experiencing this issue for the better part of a year. My AI finally pointed me to this bug (thank goodness).

Apparently it is indeed an unresolved supabase bug.

If it helps, this happens when I run my migration files on the supabase local SQL editor. Then running a db diff results in differences, even though no difference exists.

The problem is always in the function definitions.

CREATE OR REPLACE FUNCTION public.npc_world_connection_owner_check(p_world_id uuid, p_world_type text, p_user_id uuid)
 RETURNS boolean
 LANGUAGE sql
 STABLE SECURITY DEFINER
AS $function$
  select case p_world_type
    when '3d' then exists (
      select 1 from public.pu_levels l
      where l.id = p_world_id and l.user_id = p_user_id
    )
    when 'topdown' then exists (
      select 1 from public.map_projects m
      where m.id = p_world_id and m.user_id = p_user_id
    )
    when 'platformer' then exists (
      select 1 from public.stage_projects s
      where s.id = p_world_id and s.user_id = p_user_id
    )
    else false
  end;
$function$
;

Supabase v2.72.7