SQL Formatter for dbt Data Engineers — Format Models Before You Commit

dbt data engineers know about sqlfluff. It is the gold standard for dbt SQL formatting in CI pipelines. The catch: sqlfluff is a heavy install (Python package, dialect-specific dependencies, configuration file), and it is overkill for the moment when you are mid-flow writing a model and just want to clean up the query before committing it.

Our browser formatter handles the in-flight case. Format your dbt model, copy back into your editor, run dbt run to test, commit. Compatible enough with sqlfluff defaults that the CI pipeline does not flag your changes. Faster than launching sqlfluff for one model.

When sqlfluff Is Overkill — and When It Is Not

sqlfluff is the right call for these cases:

• CI pipeline enforcement. Run sqlfluff lint and sqlfluff fix in GitHub Actions to enforce team-wide style.
• Pre-commit hook. Add sqlfluff to .pre-commit-config.yaml so every commit is formatted before it lands.
• Onboarding new team members. Their editor runs sqlfluff on save, ensuring their first commits match team style.
• Bulk formatting an existing project. Run sqlfluff fix --recursive to format every model in the repo.

The browser tool is the right call for these cases:

• One-off formatting while you are writing. You are mid-query, you want to clean it up before continuing. Browser is faster than running sqlfluff.
• Working on a corporate machine where you cannot install Python packages.
• Reviewing a colleague's PR — paste their query into the browser to see what it would look like properly formatted.
• Writing SQL that does not yet have a dbt project — exploration, ad-hoc, prototype work.
• Formatting SQL that contains dbt jinja — sqlfluff handles jinja but is sensitive to config; browser formatter passes jinja through as text.

Most dbt teams use both — sqlfluff in CI, browser tool for in-flight work.

Browser Formatter vs sqlfluff Defaults

The browser formatter and sqlfluff produce very similar output for most queries. Both follow these conventions:

• Uppercase keywords (configurable in both, default on).
• 2-space indent (configurable, common default).
• One column per line in long SELECT lists.
• JOINs on their own lines with ON clauses inline.
• WHERE conditions on separate lines for readability.
• Window functions with OVER clauses broken across lines.
• CTEs separated by blank lines.

Where they differ:

• sqlfluff has hundreds of configurable rules — line length, leading commas, capitalisation policy per token type, etc. The browser tool has fewer knobs.
• sqlfluff understands dbt jinja — it can lint inside {% if %} blocks. The browser tool treats jinja as opaque text.
• sqlfluff outputs lint errors — the browser tool only formats. For linting, you still need sqlfluff.

For most ad-hoc formatting, the browser tool produces output that sqlfluff would accept on the next CI run. If your team has highly customized sqlfluff rules, double-check after formatting.

How to Format a dbt Model in Your Browser

1. Open your dbt model in your editor — VS Code, Cursor, vim, whatever you use.
2. Copy the entire model — including the {{ config(...) }} block and any jinja.
3. Paste into our formatter.
4. Pick the dialect — match your warehouse: BigQuery, PostgreSQL (Redshift), Snowflake (use BigQuery), Standard (Databricks).
5. Set indent to 2 spaces — the dbt convention.
6. Toggle uppercase keywords on.
7. Click Format. The SQL portions will be reformatted; jinja blocks will pass through as text.
8. Copy and paste back into your model, replacing the original.
9. Run dbt parse to verify the model still compiles correctly.
10. Run dbt run --select your_model to verify execution.
11. Commit and push — your CI pipeline running sqlfluff should accept it.

Sell Custom Apparel — We Handle Printing & Free Shipping

How the Formatter Handles dbt Jinja Templating

dbt models contain jinja blocks like:

• {{ ref('upstream_model') }} — model references
• {{ source('database', 'table') }} — source references
• {% if var('include_optional') %} ... {% endif %} — conditional logic
• {% for column in get_columns(...) %} ... {% endfor %} — loops
• {{ config(materialized='incremental') }} — config blocks

The browser formatter does NOT interpret jinja. It treats jinja blocks as opaque text and formats around them. This means:

• The good: Your jinja is preserved exactly as written. No risk of the formatter breaking a {% if %} block.
• The catch: SQL inside a jinja block (like inside a {% for %} loop body) might not be formatted as if it were standalone SQL. The formatter sees the whole template as opaque.

For models that are mostly SQL with light jinja (ref calls, source calls, occasional config), this works fine. For models that are heavily templated (entire query inside a {% for %} loop), use sqlfluff with the dbt plugin for proper handling.

When to Use sqlfluff Over the Browser Tool

For these specific cases, sqlfluff is the right call even though the browser tool is faster:

• Linting, not just formatting. sqlfluff can flag missing semicolons, ambiguous column references, missing aliases, and many other issues. The browser tool only formats.
• Bulk reformatting. Format every model in a 500-model repo with one sqlfluff command.
• CI enforcement. Block PRs that do not match team style.
• Pre-commit hooks. Format on every commit automatically.
• Heavy jinja templating. sqlfluff with the dbt plugin understands jinja. The browser tool does not.
• Custom rule enforcement. If your team has unique style rules (leading commas, specific column ordering, etc.), sqlfluff is configurable. The browser tool is not.

For everyone else, the browser tool is faster and covers 90% of cases.

Other Browser Tools for dbt Data Teams

dbt teams use a lot of tools. These browser tools cover the most common adjacent tasks:

YAML formatter — dbt schema.yml files use YAML. Use the YAML formatter to clean up source definitions.

JSON formatter — for inspecting JSON columns from your warehouse. JSON Formatter.

SQL diff checker — for reviewing PRs to dbt models, the SQL diff tool shows what changed.

Cron expression generator — for dbt Cloud schedule definitions. Cron Generator.

Frequently Asked Questions

Will the browser formatter break my dbt jinja templating?

No. Jinja blocks are passed through as opaque text. The formatter does not interpret {% if %}, {% for %}, {{ ref() }}, or any other jinja construct. Your templating is preserved exactly as written.

Is the output compatible with sqlfluff defaults?

For most queries, yes. Both tools default to uppercase keywords, 2-space indent, one column per line, and JOIN-on-own-line conventions. If your team has heavily customized sqlfluff rules, the browser output might not match — verify with a sqlfluff lint after pasting back.

Should I replace sqlfluff with this browser tool?

No — they serve different purposes. Use sqlfluff for CI enforcement, pre-commit hooks, and bulk formatting. Use the browser tool for in-flight ad-hoc formatting while you write models. Most teams use both.

Can I format a model that uses {% for %} loops with SQL inside?

Partially. The SQL outside the loop formats cleanly. The SQL inside the loop body is treated as part of the opaque jinja block and is not separately formatted. For heavily templated models, use sqlfluff with the dbt plugin.

Does the formatter work in Cursor or VS Code?

The formatter is a browser tool — it runs in a browser tab. Cursor and VS Code have their own SQL formatting extensions. Use the browser tool when you do not have an extension installed or when you want to format quickly without configuring an editor extension.