Context
Deleting an environment or package removes the publisher's materialization records (deleteByEnvironmentId / deleteByPackage run DELETE FROM materializations) but does not DROP the physical materialized tables. This is deliberate and consistent with the documented contract — deleteMaterialization drops physical tables only when dropTables is set; otherwise "physical-table GC is the caller's responsibility." The behavior is now locked in by tests + a contract comment in #895, and was explicitly acknowledged as an intentional decision in the #888 review.
The gap
In an orchestrated deployment the control plane owns physical GC, so the leak is fine. In a standalone deployment (the built-in scheduler path) there is no such caller, so materialized tables accumulate in the warehouse with no owner after an env/package is deleted.
Proposal (optional, standalone-oriented)
Offer an opt-in cascade drop: on env/package delete, drop the physical tables recorded in each materialization's manifest before removing the records.
Design notes / gotchas:
- Must run before connection teardown — the env-delete path closes connections, so the drops have to happen while the connections are still live.
- Best-effort + metered, mirroring
deleteMaterialization({ dropTables }) (a drop failure is logged, not fatal).
- Should reuse the existing
dropMaterializedTables logic rather than duplicating DDL.
- Keep it opt-in / standalone-scoped so orchestrated deployments (where the control plane owns GC) are unaffected.
Not urgent; captured so the "should standalone auto-clean on delete?" question stays visible. Follow-up to #895 / #888.
Context
Deleting an environment or package removes the publisher's materialization records (
deleteByEnvironmentId/deleteByPackagerunDELETE FROM materializations) but does notDROPthe physical materialized tables. This is deliberate and consistent with the documented contract —deleteMaterializationdrops physical tables only whendropTablesis set; otherwise "physical-table GC is the caller's responsibility." The behavior is now locked in by tests + a contract comment in #895, and was explicitly acknowledged as an intentional decision in the #888 review.The gap
In an orchestrated deployment the control plane owns physical GC, so the leak is fine. In a standalone deployment (the built-in scheduler path) there is no such caller, so materialized tables accumulate in the warehouse with no owner after an env/package is deleted.
Proposal (optional, standalone-oriented)
Offer an opt-in cascade drop: on env/package delete, drop the physical tables recorded in each materialization's manifest before removing the records.
Design notes / gotchas:
deleteMaterialization({ dropTables })(a drop failure is logged, not fatal).dropMaterializedTableslogic rather than duplicating DDL.Not urgent; captured so the "should standalone auto-clean on delete?" question stays visible. Follow-up to #895 / #888.