Column Keys & Constraints

Automatically ingest column keys and constraints from Snowflake datasets into the Decube Catalog, giving your team immediate visibility into data model rules and relationships.

Decube now syncs column-level constraints directly from your Snowflake datasets into the Data Catalog. Constraints such as NOT NULL, UNIQUE, PRIMARY KEY, and FOREIGN KEY are captured during metadata ingestion and surfaced alongside each column — giving your data team a complete picture of the underlying data model without switching between tools.

This is a read-only, one-way sync (Snowflake → Decube). Constraints are managed at the source and reflected automatically in the Catalog on each metadata ingestion run.

What this feature syncs

Decube ingests the following column-level constraint types from Snowflake:

• NOT NULL — columns that require a value on every row

• UNIQUE — columns where all values must be distinct

• PRIMARY KEY — the column (or combination of columns) that uniquely identifies each row in a table

• FOREIGN KEY — columns that reference a primary key in another table, establishing referential integrity between datasets

Snowflake enforces NOT NULL constraints but treats UNIQUE, PRIMARY KEY, and FOREIGN KEY as informational (not enforced). Decube syncs the constraint definition as declared in Snowflake, regardless of enforcement status.

Where constraints appear in the Catalog

Column constraints are visible in the Schema Tab of any Snowflake asset in the Catalog. Each column row displays its associated constraints alongside existing metadata such as data type, description, and tags.

This makes it straightforward to:

• Identify join keys and referential relationships between datasets

• Spot columns with mandatory value requirements before running monitors or building pipelines

• Understand data model intent without querying Snowflake directly

Sync behavior

• Constraints are synced automatically as part of the standard Snowflake metadata ingestion — no additional configuration is required.

• Constraint data is refreshed on every ingestion run, keeping the Catalog aligned with your current Snowflake schema definitions.

• Constraints are read-only in the Decube UI and cannot be edited or overridden within the platform.

Supported source

• Snowflake

Limitations

• Multi-column (composite) PRIMARY KEY and UNIQUE constraints are surfaced per-column — each participating column is individually marked with the constraint type.

• CHECK constraints are not currently synced.

• Constraints must be declared in Snowflake's information schema to be visible in Decube. Constraints enforced only at the application layer are not captured.