Why your dbt project needs naming conventions (before it needs anything else)

This is a sample post so you can see how the blog works. To write a real one, duplicate this file, change the frontmatter at the top, and write markdown below it.

Every dbt project I have inherited had the same problem: not bad SQL, but bad names. stg_orders_v2_final sitting next to orders_staging_new, and nobody remembers which one feeds the revenue dashboard.

The rule of three prefixes

Keep it boring and predictable:

• stg_ — one model per source table, renamed and typed, nothing else
• int_ — joins and business logic that other models share
• mart_ — what analysts and dashboards are allowed to touch

-- models/marts/mart_orders.sql
select
    order_id,
    customer_id,
    ordered_at,
    net_revenue_eur
from {{ ref('int_orders_enriched') }}

If a model does not fit one of these buckets, that is usually the model telling you it should be two models.

Why this matters more than tests

Tests catch bugs after they exist. Naming conventions prevent a whole class of them: the duplicated logic that appears when someone cannot find the model that already does what they need.