DB Governance, One Level Deeper

A dropped database column breaks a service just as badly as a bad env value — so the same governance model is mirrored one layer deeper. The deliberate difference: a DB column has no value, it's pure structure.

Creating a database or table is silent — nobody depends on it yet. Adding or removing a column on something already inherited is the one governed change: it stages on a Branch just like an env value edit, and the fan-out below only fires once that branch is reviewed and merged.

A service can inherit a whole database, a single table, or a single column — but what it gets is the shape, not any data. A column carries no value of its own to protect, so unlike env values there's no per-service permission gate on DB writes at all: every DB write is gated by plain workspace membership and role, because there's nothing scoped to a specific service to protect here.

Structure is documented, not just listed: tables link to each other with foreign-key-style relations (imported automatically from a .sql dump's FOREIGN KEY clauses), columns carry a structured SQL type, and a migration preview generates the real ALTER TABLE statement a column change implies — so the approval conversation happens with the actual DDL on the table, not a vague description of it. Archiving a database or table cascades cleanly: children are archived and stale inheritance/relation rows are cleaned up in one transaction, so nothing points at structure that no longer exists.