dbt-checkpoint

dbt-checkpoint

Brought to you by Datacoves

dbt-checkpoint enforces quality standards before code gets committed. Datacoves takes it further: a managed DataOps platform for dbt and Airflow where governance and best practices are built into every layer.

• Private cloud or SaaS – your data, your choice
• Managed dbt + Airflow – production-ready from day one
• In-browser VS Code – onboard developers in minutes
• Bring your own tools – integrates with your existing stack, no lock-in
• AI-assisted development – connect your organization's approved LLM (Anthropic, OpenAI, Azure, Gemini, and more)
• Built-in governance – CI/CD, guardrails, and best practices included

dbt-checkpoint catches mistakes at commit. Datacoves prevents them from happening in the first place.

Explore the platform →

Goal

dbt-checkpoint provides pre-commit hooks to ensure the quality of your dbt projects.

dbt is awesome, but when the number of models, sources, and macros in a project grows, it becomes challenging to maintain the same level of quality across developers. Users forget to update columns in property (yml) files or add table and column descriptions. Without automation the reviewer workload increases and unintentional errors may be missed. dbt-checkpoint allows organizations to add automated validations improving your code review and release process.

Telemetry

dbt-checkpoint has telemetry built into some of its hooks to help the maintainers from Datacoves understand which hooks are being used and which are not to prioritize future development of dbt-checkpoint. We do not track credentials nor details of your dbt execution such as model names. We also do not track any of the dbt hooks, such as for generating documentation. The one detail we do use related to dbt is the anonymous user_id generated by dbt to help us identify distinct projects.

By default, this is turned on – you can opt out of event tracking at any time by adding the following to your .dbt-checkpoint.yaml file:

version: 1
disable-tracking: true

Setting dbt project root

You can specify a dbt project root directory for all hooks. This is particularly useful when your dbt project is not located at the root of your repository but in a sub-directory of it.

In that situation, you previously had to specify a --manifest flag in each hook.

Now, you can avoid repeating yourself by adding the dbt-project-dir key to your .dbt-checkpoint.yaml config file:

version: 1
dbt-project-dir: my_dbt_project

This way, we will automatically look for the required manifest/catalog inside your my_dbt_project project folder.

General exclude and per-hook excluding

Since dbt-checkpoint 1.1.0, certain hooks implement an implicit logic that "discover" their sql/yml equivalent for checking.

For a complete background please refer to #118.

Since the root-level exclude statement is handled by pre-commit, when those hooks discover their related sql/yml files, this root exclusion is omitted (dbt-checkpoint re-includes files that may have been excluded). To exclude files from being discovered by this logic, the exclude path/regex must be provided in each hook (#119)

List of dbt-checkpoint hooks

:bulb: Click on hook name to view the details.

Model checks:

• check-column-desc-are-same: Check column descriptions are the same.
• check-column-name-contract: Check column name abides to contract.
• check-model-columns-have-desc: Check the model columns have description.
• check-model-columns-have-meta-keys: Check the model columns have keys in the meta part.
• check-model-has-all-columns: Check the model has all columns in the properties file.
• check-model-has-contract: Check the model has contract enforced.
• check-model-has-constraints: Check the model has specific constraints defined.
• check-model-has-generic-constraints: Check the model has generic constraints defined.
• check-model-has-description: Check the model has description.
• check-model-has-meta-keys: Check the model has keys in the meta part.
• check-model-has-labels-keys: Check the model has keys in the labels part.
• check-model-has-properties-file: Check the model has properties file.
• check-model-has-tests-by-name: Check the model has a number of tests by test name.
• check-model-has-tests-by-type: Check the model has a number of tests by test type.
• check-model-has-tests-by-group: Check the model has a number of tests from a group of tests.
• check-model-has-tests: Check the model has a number of tests.
• check-model-name-contract: Check model name abides to contract.
• check-model-parents-and-childs: Check the model has a specific number (max/min) of parents or/and children.
• check-model-parents-database: Check the parent model has a specific database.
• check-model-parents-name-prefix: Check the parent model names have a specific prefix.
• check-model-parents-schema: Check the parent model has a specific schema.
• check-model-tags: Check the model has valid tags.
• check-model-materialization-by-childs: Check the materialization of models given a threshold of child models.

Script checks:

• check-script-semicolon: Check the script does not contain a semicolon.
• check-script-has-no-table-name: Check the script has no table name (is not using source() or ref() macro for all tables).
• check-script-ref-and-source: Check the script has only existing refs and sources.

Source checks:

• check-source-columns-have-desc: Check for source column descriptions.
• check-source-has-all-columns: Check the source has all columns in the properties file.
• check-source-has-description: Check the source has description.
• check-source-table-has-description: Check the source table has description.
• check-source-has-freshness: Check the source has the freshness.
• check-source-has-loader: Check the source has loader option.
• check-source-has-meta-keys: Check the source has keys in the meta part.
• check-source-has-labels-keys: Check the source has keys in the labels part.
• check-source-has-tests-by-name: Check the source has a number of tests by test name.
• check-source-has-tests-by-type: Check the source has a number of tests by test type.
• check-source-has-tests: Check the source has a number of tests.
• check-source-has-tests-by-group: Check the source has a number of tests from a group of tests.
• check-source-tags: Check the source has valid tags.
• check-source-childs: Check the source has a specific number (max/min) of children.

Macro checks:

• check-macro-has-description: Check the macro has description.
• check-macro-arguments-have-desc: Check the macro arguments have description.
• check-macro-has-meta-keys: Check the macro has meta keys.

Exposure checks:

• check-exposure-has-meta-keys: Check the exposure has meta keys.

Seed checks:

• check-seed-has-meta-keys: Check the seed has meta keys.

Snapshot checks:

• check-snapshot-has-meta-keys: Check the snapshot has meta keys.

*Test checks: