Jinja templating in dbt offers flexibility and expressiveness that can significantly improve SQL code organization and reusability. There is a learning curve, but this cheat sheet is designed to be a quick reference for data practitioners, helping to streamline the development process and reduce common pitfalls.
Whether you're troubleshooting a tricky macro or just brushing up on syntax, bookmark this page. Trust us, it will come in handy and help you unlock the full potential of Jinja in your dbt projects.
If you find this cheat sheet useful, be sure to check out our Ultimate dbt Jinja Functions Cheat Sheet. It covers the specialized Jinja functions created by dbt, designed to enhance versatility and expedite workflows.
dbt Jinja: Basic syntax
This is the foundational syntax of Jinja, from how to comment to the difference between statements and expressions.
dbt Jinja: Variable assignment
Define and assign variables in different data types such as strings, lists, and dictionaries.
dbt Jinja: White space control
Jinja allows fine-grained control over white spaces in compiled output. Understand how to strategically strip or maintain spaces.
dbt Jinja: Control flow
In dbt, conditional structures guide the flow of transformations. Grasp how to integrate these structures seamlessly.
dbt Jinja: Looping
Discover how to iterate over lists and dictionaries. Understand simple loop syntax or accessing loop properties.
dbt Jinja: Operators
These logical and comparison operators come in handy, especially when defining tests or setting up configurations in dbt.
dbt Jinja: Variable tests
Within dbt, you may need to validate if a variable is defined or a if a value is odd or even. These Jinja Variable tests allow you to validate with ease.
dbt Jinja: Creating macros & tests
Macros are the backbone of advanced dbt workflows. Review how to craft these reusable code snippets and also how to enforce data quality with tests.
dbt Jinja: Filters (aka Methods)
Fine-tune your dbt data models with these transformation and formatting utilities.
Please contact us with any errors or suggestions.
FAQ
How do you control whitespace in dbt Jinja?
Jinja preserves whitespace by default, which can produce messy compiled SQL. To strip whitespace use a dash * before a code block use {%- ... %} * after a code block use {% ... -%} * both sides, use {%- ... -%}It is recommended to prioritize readable code over clean compiled output. Do not spend significant time on whitespace control unless it is causing actual SQL errors.
How do you debug Jinja in dbt?
The fastest way to debug Jinja is to run dbt compile or dbt run-operation and inspect the output in target/compiled folder. This shows you the raw SQL your Jinja compiled to, so you can catch logic errors before they hit the warehouse. You can also use {{ print("some message") }} to print values to the terminal during a run. For advanced debugging in dbt check out our document https://docs.datacoves.com/docs/how-tos/dbt/advenced-dbt-debug/ Note, advanced debugging it is not available in dbt Cloud.
How do you pass variables into a dbt model using Jinja?
You can define variables in dbt_project.yml and access them in models with {{ var("my_variable") }}. You can also pass variables at runtime via the command line: dbt run --vars '{"start_date": "2024-01-01"}'. Variables passed via --vars take the highest precedence. It is a good practice to provide a default value using {{ var("my_variable", "default_value") }} to avoid failures when the variable is not set.
How do you run a macro directly from the command line in dbt?
Use dbt run-operation followed by the macro name and any arguments: dbt run-operation my_macro --args '{"schema_name": "my_schema"}'. This is useful for operational tasks like creating schemas, dropping tables, or running admin logic that should not be tied to a model run. Any macro in your macros/ directory is available to run-operation.
What are the three types of Jinja delimiters in dbt?
There are three delimiters, each with a distinct purpose: {{ ... }} are Expressions, used to output values, call functions like ref() and source(), or render variables. {% ... %} are Statements, used for control flow: for loops, if blocks, set assignments, and macro definitions. {# ... #} are Comments, stripped at compile time and never appear in the generated SQL. Getting these three right is the foundation for everything else in dbt Jinja.
What is Jinja in dbt and why does it matter?
Jinja is a Python-based templating language that dbt uses to make SQL dynamic. It lets you write loops, conditionals, variables, and reusable macros directly inside your SQL files. Without Jinja, you are writing static SQL that breaks the moment your logic needs to change. With it, your models become flexible, maintainable, and DRY. If you are using {{ ref() }} or {{ source() }}, you are already using Jinja.
What is loop.last and when should you use it in dbt Jinja?
loop.last is a boolean available inside a Jinja for loop that evaluates to True on the final iteration. It is most commonly used to avoid trailing commas in dynamically generated SQL column lists. Without it, your compiled SQL will include a trailing comma after the last column, which may cause a syntax error for example if not using Snowflake. Pattern: {% if not loop.last %},{% endif %} placed after each dynamic column reference.
What is the difference between a dbt macro and a Jinja variable?
A Jinja variable ({% set my_var = "value" %}) stores a value you reference within a single model. A dbt macro ({% macro my_macro(arg) %}) is a reusable block of logic you can call across multiple models and files, similar to a function in Python. Use variables for model-scoped values. Use macros when the same logic appears in more than one place.
What is the difference between a generic test and a singular test in dbt?
A generic test is a reusable Jinja macro defined in the tests/generic/ directory. It accepts arguments like model and column_name, making it applicable across multiple models via schema.yml. A singular test is a standalone SQL file in the tests/ directory that tests one specific condition on one specific model. Use generic tests for patterns you want to enforce across the project. Use singular tests for one-off validations that are too specific to generalize.
When should you avoid using Jinja in a dbt model?
Jinja adds power but also complexity. Avoid it when plain SQL is readable and sufficient. Overusing Jinja, such as turning every repeated line into a macro, makes models harder to onboard new engineers to, harder to review in pull requests, and harder to debug. The dbt community calls well-written dbt code "dbtonic" and recommends favoring readability over cleverness. If your model is mostly Jinja with little SQL, consider whether the logic belongs in a Python model or a more structured macro instead.




.png)

