Grants and access control in dbt

dbt manages table permissions natively through the grants configuration, allowing teams to declare role-based access controls in YAML alongside model code. dbt automatically applies these permissions right after building each table or view, keeping database access rules audited and version-controlled in git.

Native grants configuration

Instead of manually executing GRANT statements in database consoles, you configure permissions directly in dbt_project.yml or within individual model property files:

models:
  my_project:
    marts:
      +grants:
        select: ['reporter_role', 'bi_service_account']

When dbt runs a model, it generates the relation and immediately executes the corresponding grant commands:

• You can grant privileges such as select, insert, or warehouse-specific permissions.
• dbt inspects existing database permissions and applies only the necessary differential grant statements, avoiding redundant DDL execution.
• Permissions can be defined hierarchically across entire folders or customized per model.

This ensures permissions stay synchronized with model definitions.

Snowflake copy_grants behavior

In Snowflake, rebuilding a table with CREATE OR REPLACE TABLE completely drops existing object permissions unless explicitly instructed otherwise. If an analyst or reporting tool relies on access to fct_orders, a standard dbt table rebuild can revoke their permissions mid-day.

To prevent this in Snowflake, configure copy_grants true in your model settings:

{{ config(
    materialized='table',
    copy_grants=true
) }}

When copy_grants is enabled, Snowflake preserves all existing access privileges when replacing the underlying physical table.

Why native grants replaced post-hooks

Before dbt introduced native grants, teams managed permissions using post_hook configurations:

{{ config(post_hook="grant select on {{ this }} to role analyst_role") }}

While post-hooks work, native grants provide substantial improvements:

• Post-hooks run raw SQL unconditionally on every model build, generating unnecessary database load.
• Native grants calculate the delta between declared permissions and actual warehouse state.
• Defining grants in YAML keeps security policies clean, standardized, and easily reviewable by security auditors during pull request reviews.

Managing permissions in code establishes a reliable audit trail for compliance and governance standards.