How do you retire a column from a published mart when dashboards you don't own still read it?

## Why the view layer exists If consumers select from base tables, every physical change is a consumer-visible change and the model calcifies: nobody dares rename anything. Serving BI tools and downstream teams through a thin view layer buys indirection. The view names, orders and types the columns you promise; the table underneath is free to be reshaped, rebuilt at a different grain, or re-keyed. Retiring a column is the case that pays for the whole arrangement, because it lets you make the change in a place where reverting is a single `CREATE OR REPLACE VIEW`. ## Step 1 — find out who actually reads it The list in your head is wrong. Sources of truth, in rough order of reliability: - **Warehouse query history** — the definitive record of what has been selected and by which service account or user, over whatever retention you have. Look back at least a quarter: month-end and quarter-end consumers only appear on those days. - **BI-tool lineage or content search** — which dashboards, extracts and semantic-layer fields reference the column. - **Downstream model code** — grep the transformation repository for the column name. - **Extracts and reverse-ETL** — the consumers most likely to be forgotten, because they are unattended jobs rather than people. Expect to find consumers you have never heard of. That discovery is the point of the exercise, not a failure of it. ## Step 2 — give them somewhere to go A deprecation without a replacement is a demand, not a migration. Publish the new column or the corrected definition first, let both coexist, and write down the exact rewrite each consumer needs — "replace `customer_tier` with `dim_customer.tier_code`, values `A/B/C` map to `GOLD/SILVER/BRONZE`". Migration effort you can hand over as a diff gets done; migration effort described as a principle does not. ## Step 3 — announce it where it will be seen A dated deprecation note belongs in the data catalog next to the column definition, in the model's documentation, and in a direct message to the owners you identified. A chat announcement alone scrolls away. Include: the sunset date, the replacement, the owner to contact, and the reason. Give at least one full reporting cycle — a monthly report that runs on the 3rd needs to have run at least once after the notice. ## Step 4 — remove from the view before removing from storage This is the ordering that makes the operation cheap to reverse: ```sql -- sunset day: the contract changes, storage does not CREATE OR REPLACE VIEW rpt_customer AS SELECT customer_sk, customer_id, tier_code -- customer_tier removed FROM dim_customer; ``` If a forgotten consumer breaks, restoring the column to the view is one statement and no data movement. Only after a quiet period — long enough to cover the slowest reporting cadence you care about — do you stop populating and then drop the underlying column. ## What not to do: the zombie column The worst outcome is a column that still exists but is no longer maintained. It returns stale values, or NULLs, or a frozen snapshot from the day the pipeline stopped writing it. Every query keeps working and quietly returns wrong answers, and because nothing errors nobody investigates. If you are not going to maintain a column, remove it from the contract. "Kept for compatibility but no longer populated" is not compatibility. A related anti-pattern is the permanent deprecation: a column marked deprecated for three years, still populated, still read, with no sunset date. Deprecation without a date is documentation of an intention, not a plan. ## The deliberate-break technique, and its cost Some teams null a deprecated column for a short, pre-announced window to flush out unknown consumers who did not respond to notices. It works — silence from the notice, complaints from the canary — but it deliberately serves wrong numbers for a period, so it belongs only on internal, non-decision-bearing columns, with the window announced in advance and kept short. On anything a business decision rests on, do not do it; use query logs instead. ## Checklist an interviewer wants to hear Find consumers from logs, publish a replacement, announce with a dated sunset and a named owner, remove from the view first, wait a full cycle, then drop from storage — and never leave an unmaintained column in the contract.