relufx.
← All journal · 2025 · 12 · 04 · Method

dbt contracts: how strict is too strict

Contracts can save a warehouse, but only when they fit the pace and shape of the business.

Too little contract discipline and every downstream model becomes an archaeological dig. Analysts learn to distrust the warehouse because columns appear, disappear, or change meaning without warning.

Too much contract discipline creates a different failure. The team spends more energy satisfying the system than improving the model. When every small change needs ceremony, people route around the warehouse with spreadsheets and private extracts.

The useful middle ground starts with critical interfaces. Contract the tables that feed finance reporting, executive metrics, customer-facing analytics, or operational workflows. Leave genuinely exploratory models with more room to move.

Strictness should follow consequence. A breaking change to a compliance metric is not the same as a renamed staging column. The contract policy should reflect the blast radius, not a universal preference for control.

Ownership is the part teams skip. A contract is only useful if someone can approve changes, explain failures, and decide whether a downstream dependency should be updated or protected. Without owners, contract errors become another noisy alert channel.

Start small, publish the rules, and review them after a few releases. If contracts are catching real mistakes without slowing routine work, tighten the next boundary. If they are mostly annoying people, the model design or ownership process is probably wrong.

The right level is the one your operating cadence can actually uphold. Data quality is not proven by strict settings alone; it is proven by the team's ability to respond when those settings tell the truth.