Beyond medallion architecture: the written rules that keep a growing dbt project consistent

Bolt’s analytics engineering team found that adopting dbt alone did not ensure consistent data modeling as the organization expanded beyond 20 people, leading to inconsistent staging practices, unclear ownership, and divergent answers. In response, the team collaboratively created 14 written rules governing model structure, dependencies, ownership, and metrics. Consumer-facing tables must follow one of three defined forms and remain simple layers over intermediate models, while intermediate models are categorized as spine, feature, or metrics models. Bolt centralizes metric definitions, distinguishes re-aggregated values as features rather than duplicate metrics, assigns each dbt model a single owner, and enforces one-directional dependencies between business domains. The rules also protect against incorrect aggregation of non-additive metrics such as distinct counts by separating them into dedicated marts and requiring BI users to select a metric key. After roughly six months of use without major problems, the framework illustrates how explicit, jointly agreed data-modeling standards can help a growing dbt team maintain reliable and scalable analytics infrastructure.

No tracked trend matches for this post yet.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.