declarative sync drops partitions created by pg_partman

[fWinNcm]

Describe the bug
When running supabase db schema declarative sync the migrations include drop statements for all partitions created by pg_partman.

To Reproduce
Steps to reproduce the behavior:

1. Create the following test-table:

CREATE EXTENSION pg_partman WITH SCHEMA extensions;

CREATE TABLE public.part_test (
  id uuid DEFAULT gen_random_uuid() NOT NULL,
  ts timestamp with time zone DEFAULT now() NOT NULL,
  PRIMARY KEY (ts, id)
)
PARTITION BY RANGE (ts);

2. Run supabase db declarative sync to set up declarative schemas.
3. Start partitioning with pg_partman:

SELECT extensions.create_parent(
  p_parent_table := 'public.part_test',
  p_control := 'ts',
  p_type := 'range',
  p_interval := '7 days',
  p_premake := 7
);

4. Run supabase db schema declarative sync to generate a new migration.
5. The migration includes drop tables for the partitions:

Generated migration SQL:
DROP TABLE public.part_test_default;
DROP TABLE public.part_test_p20260415;
DROP TABLE public.part_test_p20260422;
DROP TABLE public.part_test_p20260429;
DROP TABLE public.part_test_p20260506;
DROP TABLE public.part_test_p20260513;
DROP TABLE public.part_test_p20260520;
DROP TABLE public.part_test_p20260527;
DROP TABLE public.part_test_p20260603;
DROP TABLE public.part_test_p20260610;
DROP TABLE public.part_test_p20260617;
DROP TABLE public.part_test_p20260624;
DROP TABLE public.part_test_p20260701;
DROP TABLE public.part_test_p20260708;
DROP TABLE public.part_test_p20260715;
DROP TABLE public.part_test_p20260722;

Expected behavior
Partitions created by pg_partman should not be considered when creating statements.
Ideally I would like to be able to define a filter that get passed along to pg_delta.
Maybe as a command flag or even better in config.toml.

supabase db schema declarative sync --filter '{"not":{"table/is_partition":true}}'

System information

• Version of OS: Ubuntu 24.04 (WSL)
• Version of CLI: v2.104.0
• Version of Docker: v29.4.2
• Versions of services:
  • supabase/postgres: 17.6.1.084
  • supabase/gotrue: v2.188.1
  • postgrest/postgrest: v14.4
  • supabase/realtime: v2.102.1
  • supabase/storage-api: v1.43.3
  • supabase/edge-runtime: v1.74.0
  • supabase/studio: 2026.05.25-sha-65c570e
  • supabase/postgres-meta: v0.96.6
  • supabase/logflare: 1.42.0
  • supabase/supavisor: 2.9.5

Potential workaround
I could put the partitioning in a seed file and do the following:

supabase db reset --no-seed # reset database without seeding
supabase db schema declarative sync --no-apply # generate migrations without partman tables
supabase db reset # apply the new migration and seed

This would work fine as a workaround for now.
On prod i would just start the partitioning once manually.