Further Reading: dbt

Sources are tagged Tier 1 (confident it exists, recommended without reservation) or Tier 2 (real and worth seeking, but confirm the current edition, version, or URL yourself).

A warning specific to this chapter. dbt moved fast between 2019 and 2024, and a great deal of confidently-worded material describes a version nobody runs. Metrics left dbt-core in 1.6, unit tests arrived in 1.8, snapshot configuration moved to YAML in 1.9. Check the date on anything you read, and prefer the versioned documentation over a blog post whose examples look familiar.

The primary sources

• The dbt documentation at docs.getdbt.com. Unusually good, and versioned — the version selector in the corner is the most important control on the page. The sections worth reading end to end rather than searching: "Materializations," "About dbt tests," "Node selection syntax," and "About state" (which is what makes §19.14 work). The node-selection page in particular repays a slow read; most people learn --select model and never discover @, state:, or set operations. Tier 1 — versioned; confirm you are reading 1.9 or later.

• The dbt "Best Practices" guides, in the same documentation. The staging/intermediate/marts layout in §19.5 is theirs, and the guides state the reasoning behind each convention rather than only the convention. Read "How we structure our dbt projects" before your first project and again after your fiftieth model; different parts of it become obvious at different times. Tier 1.

• The dbt_utils package README, at github.com/dbt-labs/dbt-utils. Read the whole thing once. It is short, and roughly a third of the macros solve a problem you are about to solve worse — unique_combination_of_columns (the grain test), expression_is_true (the volume assertion), date_spine, star, union_relations. Tier 1.

• The manifest.json schema documentation. dbt publishes a JSON schema for the artifacts it writes. This chapter's manifest_audit.py is built on it, and so is every serious dbt tooling project. The manifest is the reason dbt is programmable, and reading its structure once changes what you think is possible to enforce. Tier 2 — the schema is versioned and the URL has moved; find it via the "dbt Artifacts" documentation page.

Books

• Joe Reis and Matt Housley, Fundamentals of Data Engineering (O'Reilly, 2022). Chapter 8 covers transformation and puts dbt in the context of what preceded it, which is the perspective this chapter mostly assumes rather than supplies. The historical framing is the value — dbt looks inevitable until you see the twenty years of stored procedures and Informatica jobs it displaced, and the specific pains it was responding to. Tier 1.

• Ralph Kimball and Margy Ross, The Data Warehouse Toolkit (3rd ed., Wiley, 2013). Referenced in Chapter 6 and again here because the fct_/dim_ layout in §19.5 is Kimball's, and dbt did not invent it. Understanding the modelling this project layout expresses is what makes the layout feel like reasoning rather than convention. Tier 1.

• Lauren Balik and the critical dbt commentary of the mid-2020s. There is a genuine dissenting literature arguing that dbt encourages sprawl — hundreds of models, unclear ownership, warehouse bills nobody can attribute. Read some of it. §19.5's two degenerate shapes come from that criticism being correct about real projects, and a practitioner who has only read advocacy will build one of them. Tier 2 — blog and social-media commentary; scattered and opinionated by design.

On the specific failures in this chapter

• The dbt documentation on source freshness, and then go and check whether your project runs it. §19.8 and Case Study 2 are about a feature that is configured far more often than it is invoked, and the documentation does not tell you that because documentation describes what things do, not what organizations forget. Tier 1 for the docs; the checking is on you.

• Google's Site Reliability Engineering (O'Reilly, 2016), the chapters on monitoring and on postmortems. Two things transfer directly. The monitoring chapter's distinction between symptoms and causes is why Case Study 1's volume assertion belongs on the fact rather than on the loader. The postmortem chapter's insistence on action items with owners is the ancestor of Case Study 2's required data-impact field. Free online. Tier 1.

• John Allspaw and the "blameless postmortem" literature. Case Study 1's known-issues entry was written by someone doing their job well under time pressure, and Case Study 2's alert routed to an archived channel nobody chose to archive maliciously. The framing that treats both as system properties rather than individual failures is what makes the fixes structural — a linter rather than a checklist, a fire drill rather than a reminder. Tier 2 — talks and blog posts.

Practice and tooling

• The dbt Learn courses at courses.getdbt.com. Free, official, and the fastest way from zero to a working project. Do the fundamentals course even if you have used dbt for a year — it covers the node-selection and state material that most self-taught users have never touched. Tier 2 — free but account-gated; check current availability.

• sqlfluff, at sqlfluff.com. A SQL linter with a dbt templater, so it lints the compiled SQL and understands ref(). Formatting consistency in a ninety-model project is worth more than it sounds: it removes a whole category of pull-request comment, and it makes the diffs that remain about substance. Tier 2 — actively developed; the dbt templater configuration changes.

• elementary and the open-source dbt observability tools. They read run_results.json and manifest.json — the same artifacts as this chapter's audit — and build dashboards of test failures, model runtimes, and freshness over time. Worth evaluating once your project passes fifty models; before that, the audit script and a look at the logs is enough, and the tooling is a distraction from writing the three assertions that would actually catch something. Tier 2 — an active project; verify the current name and scope.

A note on what to be skeptical of

The genre of "we replaced our entire data stack with dbt and saved N%" deserves the same scrutiny Chapter 11 §11.6 applied to format benchmarks. The savings are usually real and usually attributable to something else — a rebuild is an opportunity to delete the forty models nobody used, and deleting them would have worked without dbt.

dbt's real contribution is narrower and more durable than the case studies claim: the dependency graph is derived rather than maintained, the tests live with the models, and the whole thing is plain text in version control. That is enough. It does not need the rest.