SnowDDL
  • 👋Introduction
  • ðŸšĐGetting started
  • 📋Main features
  • ðŸŠĪSnowDDL vs. Declarative DCM
  • In-depth guides
    • 👓Object identifiers
    • 📐Data types
    • ðŸ“ĶObject types
    • 🎭Role hierarchy
    • 🚧Permission model
    • ðŸ”ĶOther guides
      • Administration user
      • Integrations
      • Inbound shares
      • Object OWNERSHIP
      • Safe & unsafe DDL
      • Dependency management
      • Short hash explained
      • Env Prefix explained
      • Team workflow
      • Limitations & workarounds
      • Fivetran
      • Airbyte
      • Encrypt user passwords
      • Iceberg Tables
  • Basic usage (CLI + YAML)
    • ðŸ’ŧCLI interface
    • ðŸ“ĶYAML configs
      • ACCOUNT PARAMETER
      • ACCOUNT POLICY
      • AGGREGATION POLICY
      • ALERT
      • AUTHENTICATION POLICY
      • BUSINESS ROLE
      • DATABASE
      • DYNAMIC TABLE
      • EVENT TABLE
      • EXTERNAL ACCESS INTEGRATION
      • EXTERNAL FUNCTION
      • EXTERNAL TABLE
      • FILE FORMAT
      • FUNCTION
      • HYBRID TABLE
      • ICEBERG TABLE
      • MASKING POLICY
      • MATERIALIZED VIEW
      • NETWORK POLICY
      • NETWORK RULE
      • PERMISSION MODEL
      • PIPE
      • PLACEHOLDER
      • PROCEDURE
      • PROJECTION POLICY
      • RESOURCE MONITOR
      • ROW ACCESS POLICY
      • SCHEMA
      • SECRET
      • SEQUENCE
      • SHARE (outbound)
      • STAGE
      • STAGE FILE
      • STREAM
      • TABLE
      • TASK
      • TECHNICAL ROLE
      • USER
      • VIEW
      • WAREHOUSE
    • 🏷ïļYAML placeholders
    • 📎YAML tag !include
    • 🔐YAML tag !decrypt
  • Single DB
    • ðŸĶ€Overview
  • Advanced usage (Python)
    • ⚙ïļProgrammatic config
    • 🐍Architecture overview
      • ðŸ”ĩBlueprints
      • ðŸŸĢConfig
      • 🟠Parsers
      • ðŸŸĒResolvers
      • ðŸ”īEngine
    • 🏗ïļQuery builder & formatter
  • Breaking changes log
    • 0.45.0 - March 2025
    • 0.41.0 - January 2025
    • 0.37.0 - December 2024
    • 0.36.0 - November 2024
    • 0.33.0 - October 2024
    • 0.27.0 - May 2024
  • Links
    • GitHub repository
    • PyPI package
    • YouTube tutorials
    • Changelog
    • LinkedIn profile
Powered by GitBook
On this page
  • What is permission model?
  • Grants
  • Rulesets
  • Setting permission model
  1. In-depth guides

Permission model

PreviousRole hierarchyNextOther guides

Last updated 12 months ago

What is permission model?

Permission model is a special concept introduced by SnowDDL to help managing permissions for databases and schemas. Permission model holds information about CREATE GRANTS and FUTURE GRANTS.

Permission models are optional. If you do not set it explicitly, DEFAULT model will be used for all schemas. You may check the specific configuration of DEFAULT model on .

Grants

Permission model allows you to specify the following types of grants:

  • OWNER create grants - which types of objects can be created by OWNER role;

  • OWNER future grants - which future grants should be applied to OWNER role (usually OWNERSHIP)

  • WRITE future grants - which future grants should be applied to WRITE role

  • READ future grants - which future grants should be applied to READ role

Rulesets

Additionally, you may choose one of two "rulesets" defining how grants should be applied. Currently available rulesets are called: SCHEMA_OWNER and DATABASE_OWNER.

Here is the comparison table:

SCHEMA_OWNER
DATABASE_OWNER

Selected by default

Must be configured explicitly

OWNER role is created on schema level

OWNER role is created on database level

OWNER cannot create new schemas

OWNER can create new schemas

Schemas are owned by SnowDDL admin

Schemas are owned by OWNER role

Schemas are created with MANAGED ACCESS

Schemas are created without MANAGED ACCESS

READ and WRITE roles are created on schema level

READ and WRITE roles are created on database level, but additionally on schema level for each explicitly configured schema

DATABASE_OWNER ruleset is typically used for external tools which absolutely require ability to create their own schemas, such as Fivetran, Airbyte, etc.

Setting permission model

If permission model is set on DATABASE level, all its SCHEMAS inherit it by default.

You can mix & match different permission models across different schemas, but the ruleset on all models in one DATABASE must be the same.

Define permission models(s) in .

Set permission model(s) in or configs.

🚧
this page
config
DATABASE
SCHEMA