dbt

Run the dbt warehouse tests starter end to end

Clone the dbt-warehouse-tests starter, seed its deterministic customers and orders data, and build the staging → intermediate → marts pipeline with dbt build --target dev.

The warehouse mental model — micro-partitions, clustering, scan vs compute

Build the map before tuning anything: a table is a set of micro-partitions, every query is described by bytes scanned, partitions scanned ratio, and queue time, a clustering key decides how much gets pruned, and a slow query is either a scan problem or a compute problem — never both at once.

Write the minimum dbt test set for a model

Start from the model's grain, then rank dbt tests by the cost of the failure they prevent: uniqueness and not-null on the grain key, relationships on foreign keys, accepted values on enums, and freshness on sources.

Capstone — the warehousing checklist, end to end

Close the series by auditing one warehouse project against everything it taught: models with tests and docs, layered staging to marts with a declared grain, incremental loads with a lookback, CI on a staging schema, monitored query history, and a repo structure a new joiner can read.

Incident — the dashboard query that went slow

Run the slow-query runbook as an incident: confirm the regression, split scan cost from compute contention, pull partitions_scanned and bytes from query history as evidence, apply the matched fix, and escalate on the shared-warehouse SLA before the queue takes other teams down with it.

Make queries prune — clustering keys and scan diagnosis

Choose a clustering key from the predicates of your most expensive queries, prove the prune with partitions_scanned versus partitions_total, and fix the disease you actually have — a lost predicate or a low-selectivity key on the scan side, or queue time on the compute side.

Model a star schema — facts, conformed dimensions, declared grain

Turn the analytical layer into facts surrounded by conformed dimensions: declare the fact grain in schema.yml, stage and intermediate models below it, SCD2 where history must survive, and scaffold the whole thing from the dbt project template so staging, marts, tests, and CI exist from commit one.

Review a dbt model PR before merge

Take a pull request that adds or changes a dbt model and walk the reviewer's pass: read the diff in context, state the model's grain and check it against the unique key test, choose table vs incremental vs view deliberately, and handle late-arriving data in the incremental filter.

Run dbt model review and tests from the workbench plugin

Install the dbt Workbench plugin and drive one model change through its three commands: /dbt-review-model for the model review, /dbt-write-tests for a proposed test set, and /dbt-impact before you merge.

Warehouse production gotchas — cost, full refreshes, late data

The three ways a healthy warehouse model hurts production: a full-refresh that rebuilds a 4B-row table unannounced, a lookback window too short to catch late-arriving orders, and cost drift nobody reviews.

dbt Test Writer

• Rank tests by the cost of the failure they prevent
• Write a custom singular test

dbt Model Review

• State a model's grain and match it to its unique key test
• Choose table vs incremental vs view deliberately

dbt MCP Server

dbt Labs server that exposes project discovery, the semantic layer, and the dbt CLI (`run`, `test`, `compile`) as tools, so an agent can build and inspect models.

dbt Workbench

Model review, test generation, incremental-safety checks and a full-refresh guard, plus the dbt MCP server for running commands from the agent.

dbt Full-Refresh Guard

Require confirmation before a full-refresh of a large incremental model.

dbt Project Template

A layered dbt project (staging/intermediate/marts) with tests, docs, a CI workflow that builds against a staging schema, and a source freshness config.

dbt → warehouse → tests → docs

Transform raw landed data into a tested, documented star schema with dbt, and gate every change on data-aware CI.

dbt as Models + Tests + Docs

Transformation logic lives in untested, undocumented SQL scattered across scripts.

dbt Best Practices Guide

dbt Labs' official best practices guide — project structure, staging/marts layering, naming conventions, testing conventions (unique, not_null, relationships, accepted_values), model contracts, and incremental model patterns. A widely-adopted convention set; agreeing on it early avoids enormous friction later. The testing conventions section directly backs our dbt test writer skill; the materialization guide supports our warehouse testing patterns.

dbt Documentation

dbt's documentation — the analytics-engineering workflow, project structure with models and sources, materialisations and incremental-model patterns, tests (unique, not-null, relationships, accepted values) and the docs-as-data approach. The materialisation and incremental-model pages are the reference behind our dbt review and testing skills; pair with our warehouse-testing guide for the practical path.