Macros

A macro is a reusable chunk of Jinja + SQL defined with {% macro macro_name(args) %} ... {% endmacro %} and saved in a .sql file inside the macros/ directory, callable from any model using {{ macro_name(args) }} just like a function call. Macros exist to eliminate copy-pasted SQL patterns — instead of writing the same CASE WHEN currency-conversion logic in fifteen different models, you write it once as a macro and call it everywhere it's needed.

dbt ships several built-in macros you use constantly without writing them yourself, like {{ dbt_utils.generate_surrogate_key([...]) }} from the popular dbt_utils package for hashing multiple columns into a single primary key, or {{ dbt_utils.date_spine(...) }} for generating a calendar table. Installing a community package like dbt_utils via packages.yml and running dbt deps gives your whole team access to dozens of battle-tested macros for common patterns like pivoting, unioning tables with different schemas, and testing, without anyone having to reinvent them.

Macros can accept default argument values, call other macros, and even use {% set %} to define local variables, giving them real function-like behavior beyond simple text substitution — but unlike a model, a macro produces no table or view on its own; it only exists to be called from somewhere else. Advanced teams can even override built-in dbt materializations themselves, such as redefining the incremental materialization's default merge behavior, by creating a macro with the exact reserved name dbt expects, like default__incremental, inside their own project or a package.