➡️ Introducing Data Lineage in DBML

Every number in a report comes from a table, which was built from another table before it. Until now, DBML could only say that two tables are related by a foreign key. Data lineage lets you say that one is built from the other, using Dep, and dbdiagram draws it, so a data team can see the whole pipeline at a glance, and read what each step does along the way.

// one line per step
Dep: stripe_payments -> daily_orders

// or map the columns, and pull several tables into one
Dep monthly_revenue_build {
  daily_orders.amount     -> monthly_revenue.revenue
  daily_orders.ordered_at -> monthly_revenue.month
  refunds.amount          -> monthly_revenue.refunds

  note: 'Adds up orders by month, minus refunds.'
}

Why it matters:

• Design before you build. One line per step is enough to sketch a whole pipeline in plain text, and get review on its shape before any SQL exists.
• Answer "where does this number come from". Map single columns, then click one in the diagram and every table it travelled through lights up.
• Schema and flow on one canvas. Ref and Dep draw as different edge styles, so you can show them together or separately, whichever the diagram needs.
• Notes explain what each step does. Add a note to any dependency to describe the step in plain words, so the meaning sits beside the arrow instead of in a separate doc.

Reading lineage straight from a dbt project or your warehouse is what we are working on next.

Note: Data lineage is available on all plans, with no limit on project size.

📚 Read the full syntax docs →

Please give it a try and let us know what you think.