Cloud warehouses removed the old constraints. Storage is cheap, compute scales on demand, and adding a table costs nothing. That is precisely the problem. When creating something has no friction, things get created. Almost nothing gets removed.
A warehouse rarely becomes unusable because it grew too large. It becomes unusable because it accreted. Tables nobody owns sit next to three versions of the same metric, fed by pipelines whose authors left years ago. The data is all there. Knowing which of it to trust is the part that quietly breaks.
Sprawl is a process failure, not a storage one
Every individual decision that produces sprawl is reasonable in the moment. Someone needs a number by Friday, so they build a table. Someone else cannot find that table, so they build their own. A definition shifts, so a _v2 appears beside the original, and the original is never deleted, because no one is certain what still depends on it.
Multiply that across a year and the warehouse holds several plausible answers to every important question. The cost is not disk space. It is the meeting where two teams present different revenue figures and neither can say which is correct.
Structure the warehouse in deliberate layers
The single most effective defence against sprawl is a small number of layers, each with a clear rule about what belongs in it:
- The raw layer holds source data landed as-is, never queried directly by reporting. It is the untouched record of what arrived.
- The staging layer is cleaned and standardised: types fixed, columns renamed consistently, obvious errors handled. Still close to the source, but predictable.
- The marts layer holds the modelled tables people actually query, built to answer the questions the business asks. These are designed, owned, and documented.
When every table has an obvious home, an unowned table in the wrong layer becomes visible rather than blending into the mess.
One definition per metric
The most expensive ambiguity in any warehouse is the metric that means three different things. “Active customer”, “revenue”, “churn”: each should be defined once, in one modelled table, with every report drawing from that definition rather than re-deriving it.
This is less a technical rule than an organisational one. It requires someone to own the definition, and the standing to say no when a fourth slightly different version gets requested. The alternative is the recurring argument about whose number is right. No dashboard can settle that one.
Make removal as normal as creation
Sprawl persists because deletion feels risky and creation feels free. Rebalancing that is mostly discipline:
- Assign an owner to every table that survives. A table no one will claim is a table no one should trust, and a candidate for removal.
- Deprecate on a schedule: mark unused tables, give dependants notice, then actually remove them. A warehouse that only ever grows only ever gets harder to use.
- Document the modelled layer, not everything. The marts people rely on deserve a clear description of what each table and column means. Raw and staging can stay lightly documented; the layer people query cannot.
None of this requires heavy governance or a new tool. It requires treating the warehouse as a product with an owner, rather than a shared drive that anyone can add to and no one maintains.
The same discipline underlies a single source of truth: agreeing what is true and writing it down once. And if the prior question is still open, whether a warehouse is even the right store for what you are doing, that is covered in data warehouse vs data lake. Keeping a warehouse trustworthy as it grows is part of what our data solutions practice does.
