dbt Tags: Grouping and Selectively Running Models

Folder structure gives you one way to group models — by domain, by layer — but it’s a single, fixed hierarchy. Sometimes you need a different, orthogonal grouping: every model that touches PII, every model that’s part of the nightly-only batch, every model owned by the finance team regardless of which folder it physically lives in. dbt tags exist for exactly this — a flexible, many-to-many way to label and select models that doesn’t require restructuring your directory layout.

Applying Tags

Tags can be set inline in a model’s config, or centrally in dbt_project.yml for an entire folder.

-- models/finance/monthly_revenue.sql
{{ config(tags=['finance', 'nightly']) }}

select ...

# dbt_project.yml — applies a tag to every model in a folder
models:
  my_project:
    finance:
      +tags: ['finance']

A model can have both a folder-level tag inherited from dbt_project.yml and additional tags added at the individual model level — they combine rather than override.

Selecting by Tag

# Run every model tagged 'finance'
dbt run --select tag:finance

# Run models tagged 'nightly' but exclude anything tagged 'deprecated'
dbt run --select tag:nightly --exclude tag:deprecated

# Combine with graph selectors
dbt run --select tag:finance,stg_orders+

This is the same selection syntax used throughout this series (covered in dbt run) — tags are just another dimension you can select on, alongside model names and folder paths.

Common Tagging Patterns That Scale

By execution frequency, separating models that need to run every 15 minutes from ones that only need a nightly refresh:

dbt run --select tag:realtime    # scheduled every 15 min
dbt run --select tag:nightly     # scheduled once daily

By data sensitivity, useful for applying different access controls or masking logic to a specific subset regardless of folder:

models:
  - name: customer_pii_details
    config:
      tags: ['pii']

# A security audit script can find every PII-tagged model instantly
dbt ls --select tag:pii

By team ownership, when a project spans multiple teams and each wants to run or monitor only their own models:

dbt run --select tag:team_finance
dbt test --select tag:team_marketing

Tags vs. Folder Structure: When to Use Which

A model can only live in one folder, but it can carry as many tags as make sense — a finance model that also happens to contain PII and runs nightly can carry all three tags simultaneously, something folder structure alone can’t express.

Combining Tags With CI Pipelines

Tags are a natural way to scope different CI checks to different subsets of a large project without needing separate dbt projects.

# Example CI configuration
fast_pr_check:
  command: "dbt build --select tag:critical_path"
full_nightly_validation:
  command: "dbt build"

A pull request check can validate only the highest-priority, fastest-to-run subset tagged critical_path, while a full nightly job validates everything — a meaningful speed tradeoff for fast PR feedback without sacrificing full coverage entirely.

Inspecting What’s Tagged What

dbt ls --select tag:finance --output json

This lists every model carrying a given tag, useful as an audit step — confirming that every model that’s supposed to be tagged actually is, since a missing tag on a new model silently excludes it from whatever selective runs or checks rely on that tag.

Excluding Tags, Not Just Selecting Them

Beyond --select tag:x, --exclude is often the more precise tool when the majority of a project should run except for a small, clearly-tagged subset.

# Run everything except models still under active development
dbt build --exclude tag:wip

# Run everything except known-expensive, rarely-needed models
dbt build --select finance.* --exclude tag:heavy_backfill_only

This combination — a broad selection with a targeted exclusion — is often easier to maintain than an equivalently broad inclusion list, since new models added to a folder are automatically included in future runs unless explicitly tagged out, rather than needing to be manually added to an inclusion list every time.

Auditing Tag Coverage Across a Project

On a project that’s been growing for a while, it’s worth periodically checking which models have no meaningful tags at all — often a sign they were added before a tagging convention was established, or slipped through review.

dbt ls --output json --output-keys unique_id,tags | jq 'select(.tags == [])'

This surfaces every untagged model in one pass, giving you a concrete backlog of models to bring in line with whatever tagging convention the rest of the project follows.

Common Mistakes

Relying on tags without a convention for what tags exist. Without a documented list of “these are our tags and what each means,” different engineers invent slightly different tag names for the same concept (fin vs finance vs Finance), fragmenting selection queries silently.

Forgetting to tag new models that should inherit a project-wide category. A tag applied at the individual model level, rather than centrally at the folder level in dbt_project.yml, is easy to forget on a newly added model — prefer folder-level tag inheritance wherever the grouping genuinely maps to folder structure.

Using tags for something that graph selection already handles better. If you find yourself tagging every model in a folder just to select that folder, --select finance.* (a path-based selector) already does that without needing a tag at all — tags earn their value specifically for groupings that don’t align with folder structure.

Summary

Tags give a dbt project a second, flexible axis of organization on top of folder structure — most valuable exactly where a model’s grouping doesn’t map cleanly onto where it physically lives in the repository.