Declarative schema migration generation broken for JOIN views after CLI update

[vanandtwocrows]

Describe the bug After upgrading to the latest Supabase CLI (2.34.3), supabase db diff in declarative schema mode is endlessly re-generating migrations for views that contain JOINs, even if no actual changes have been made to the view SQL.

Before the CLI update, these views were stable. Now, after every db diff, the same DROP VIEW / CREATE VIEW statements are produced, leading to an infinite migration loop.

---

To Reproduce Steps to reproduce the behavior:

1. Upgrade to the latest Supabase CLI
2. Have a project using declarative schema (supabase/schemas/*.sql).
3. Include a view with a join, for example:

create or replace view public.timeslips_view as
select
  o.name,
  tr.timeslips_requested,
  tr.created_at,
  tr.download_link,
  tr.modified_at
from public.timeslips_requests tr
left join public.organisations o on tr.organisation_id = o.id
order by tr.created_at desc;

4. Create migration with supabase stop && supabase db diff -f migration_name
5. Re-run the diff

---

Expected behavior If no changes have been made to the database or declarative schema, supabase db diff should produce no output.

---

Actual behavior The CLI repeatedly outputs the same DROP VIEW / CREATE VIEW statements for affected views. This repeats indefinitely after each run, even immediately after applying the migration.

---

Notes / Observations • The issue appears specific to views containing JOINs — views without joins are unaffected. • Happens whether or not schema qualification (public.) is used in the FROM clause. • Removing WITH (security_invoker...) and ALTER ... OWNER from the declarative schema does not resolve it. • Likely linked to a change in the CLI’s SQL deparser in the most recent release.

[nicksiscoe]

Noticing exact same behavior when upgrading to 2.34.3. If I revert to 2.34.0 this bug doesn't happen.

[lavisht22]

Did you find any solutions to this? I don't have declarative schemas and this is still happening with me.

[nicksiscoe]

Did you find any solutions to this? I don't have declarative schemas and this is still happening with me.

@lavisht22 Updating to latest supabase cli seems to work for me. Currently on 2.40.7

[YA9]

Getting the same issue

[speedpro]

I'm getting the same issue, but mine doesn't have a join:

create or replace view "public"."active_items" as
SELECT 
  item.id,
  item.name,
  ...
FROM items WHERE (item.is_deactivated = false);

It's odd. I had only one view which was stuck in this loop, but since switching to declarative schemas, I now have three views which are stuck in this loop.

[nicksiscoe]

This was briefly fixed for a few versions and has come back on the latest few versions... No issues on 2.40.7-ish but on latest it's broken again

[jperasmus]

Is there a known workaround for this for now? I think the limitation I am running into is because my views have security_invoker set, which I see is part of the known limitations. It recreates the views every time I run the diff.

[jdharrisnz]

@jperasmus Switching the diff tool with --use-pg-schema worked for me. The default migra hasn't been updated in years, and I read that Supabase will be changing the default to pg schema in the future. As always, closely check your migration files!

[jperasmus]

Thanks @jdharrisnz I tried pg-schema-diff now, which looked promising. Unfortunately, it looks like it doesn't currently support indexes on materialized views, so it is erroring out for me. https://github.com/stripe/pg-schema-diff/issues/173

[chaintng]

having same issue also

[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