Compare

dbt-checkpoint vs SQLFluff

SQLFluff lints and auto-formats SQL itself; dbt-checkpoint enforces governance rules a linter can't see, like missing descriptions or untested keys.

Side by side

dbt-checkpoint SQLFluff
Vendor Datacoves (open source project) SQLFluff (open source project)
Pricing model Open source + paid options Open source + paid options
Free tier Yes Yes
Deployment Self-hosted Self-hosted
Open source Yes (MIT) Yes (MIT)
Best for Teams wanting governance and documentation standards enforced locally before a dbt model reaches CI. Analytics engineering teams wanting consistent, auto-fixable SQL style enforcement across a dbt codebase.
Pricing

Free, open-source pre-commit hook library; no paid tiers.

Pricing has not been verified yet — see the vendor's site.

Free, open-source CLI tool; no paid tiers.

Pricing has not been verified yet — see the vendor's site.

Features
  • Pre-commit hooks enforcing model documentation standards
  • Checks for missing tests on key columns
  • Naming and folder-structure convention checks
  • Local, pre-push validation rather than CI-only
  • Configurable hook selection per project
  • Works with dbt Core, dbt Cloud, Datacoves and Paradime
  • Configurable SQL linting across multiple dialects
  • Auto-fix for most rule violations
  • Dedicated dbt templater resolving ref() and macros before linting
  • CI and pre-commit integration
  • Used as the built-in linter in dbt Cloud's Studio IDE
  • Editor plugins for VS Code and others

Verdict

These two open-source, free pre-commit tools check different things, and neither substitutes for the other. SQLFluff is a dialect-flexible SQL linter and auto-formatter that understands dbt's Jinja templating well enough to resolve ref() calls and macros before linting, so most style violations — indentation, keyword casing, structural consistency — are checked against the SQL a warehouse would actually run, and most can be auto-fixed. It is also the linter built into dbt Cloud's Studio IDE.

dbt-checkpoint runs as pre-commit hooks that check governance, not syntax: whether a model has a description, whether its primary-key columns have tests, whether it sits in the right folder under your team's naming convention. A perfectly formatted model can still fail a dbt-checkpoint hook for having no tests, and a well-documented, well-tested model can still fail a SQLFluff check for inconsistent casing.

In practice the two are complementary rather than competing, and most teams that adopt one eventually add the other: SQLFluff keeps the SQL itself readable and consistent as more people contribute, while dbt-checkpoint keeps the surrounding governance — descriptions, tests, structure — from quietly decaying as the project grows past what a single reviewer can check by eye on every pull request.

Choose SQLFluff if

  • Inconsistent SQL style across contributors is the immediate pain point.
  • You want violations auto-fixed rather than only flagged.
  • You want the same linter used inside dbt Cloud's own IDE.

Choose dbt-checkpoint if

  • Models are merging without documentation or tests on key columns.
  • You want naming and folder-structure conventions enforced locally, before a commit is even pushed.
  • You are already covered on SQL style and the gap is project governance instead.

What they share

Both are free, MIT-licensed pre-commit hooks that run locally before code reaches CI, both are commonly used with any dbt setup — dbt Core, dbt Cloud, Datacoves or Paradime — and neither checks whether the resulting data is actually correct. For that layer, see choosing a data quality testing tool or Recce for reviewing the data impact of a specific pull request.

Last reviewed September 22, 2026

In the index now