Snowflake Provider

Deploy data products to Snowflake Data Cloud (databases, schemas and tables) using the same contract format and CLI commands as the other providers.

Status: ✅ Production
Docs Baseline: CLI 0.18.1
Tested Services: Databases, Schemas, Tables

Why it matters Target Snowflake with the same contract your other teams run elsewhere — no Snowflake-specific rewrite. Set binding.platform: snowflake and fluid apply compiles the contract to an OpenTofu module for the snowflakedb/snowflake provider and runs it.

Overview

The Snowflake provider turns a FLUID contract into real Snowflake infrastructure:

• ✅ Plan & Apply: databases, schemas and tables (with cluster_by) through OpenTofu
• ✅ Sovereignty validation: region constraints checked before deployment
• ✅ Orchestration generation: fluid generate schedule --scheduler airflow
• ⚠️ Access grants: fluid policy-compile turns accessPolicy.grants into Snowflake grant bindings, but as of 0.18.1 nothing applies them (see Snowflake-Native Security)
• ❌ Masking, row access and column restrictions: the contract's policy.privacy and policy.authz.columnRestrictions fields are not read on Snowflake (see Governance Features)
• ✅ Universal Pipeline: the same Jenkinsfile as GCP and AWS

Choose Your Starting Path

Use Snowflake in one of these two modes:

• Enterprise recommended path: dbt-snowflake plus explicit environment-specific warehouse, database, schema, and role settings. Start with the billing_history example and the Snowflake quickstart.
• Minimal starter path: native SQL with the smoke example when you want the smallest contract that still proves auth, validate, plan, apply, and verify.

For production teams, make these explicit per environment:

• SNOWFLAKE_ACCOUNT
• SNOWFLAKE_USER
• SNOWFLAKE_WAREHOUSE
• SNOWFLAKE_DATABASE
• SNOWFLAKE_SCHEMA
• SNOWFLAKE_ROLE

For production and CI, use this authentication order:

1. SNOWFLAKE_PRIVATE_KEY_PATH for key-pair auth
2. SNOWFLAKE_OAUTH_TOKEN for federated automation
3. SNOWFLAKE_AUTHENTICATOR for interactive SSO

Password auth is still supported, but it should be treated as a fallback rather than the default production path.

If no explicit credentials are present, browser SSO is only attempted in an interactive TTY session. Non-interactive runs should supply key-pair, OAuth, or another explicit authenticator instead of relying on browser prompts.

Working Example: Bitcoin Price Tracker

The contract below provisions a Snowflake table and runs a Python ingestion build. It validates on 0.18.1, and fluid generate iac emits a database, a schema and a clustered table from it.

Contract

fluidVersion: "0.7.5"
kind: DataProduct
id: crypto.bitcoin_prices_snowflake_governed
name: Bitcoin Price Index (Snowflake)
description: >
  Bitcoin price data on Snowflake
domain: finance

tags:
  - cryptocurrency
  - real-time
  - gdpr-compliant
  - snowflake

labels:
  cost_center: "CC-1234"
  business_criticality: "high"
  compliance_gdpr: "true"
  compliance_soc2: "true"
  platform: "snowflake"

metadata:
  layer: Gold
  owner:
    team: data-engineering
    email: data-engineering@company.example.com

# ── Data Sovereignty ──────────────────────────────────────────
sovereignty:
  jurisdiction: "EU"
  dataResidency: true
  allowedRegions:
    - eu-west-1          # Snowflake AWS Europe (Ireland)
    - eu-central-1       # Snowflake AWS Europe (Frankfurt)
    - europe-west4       # Snowflake GCP Europe (Netherlands)
  deniedRegions:
    - us-east-1
    - us-west-2
    - us-central1
  crossBorderTransfer: false
  transferMechanisms:
    - SCCs
  regulatoryFramework:
    - GDPR
  enforcementMode: advisory
  validationRequired: true

# ── Access Policy: Snowflake RBAC ─────────────────────────────
accessPolicy:
  grants:
    - principal: "role:DATA_ANALYST"
      permissions: [read, select, query]

    - principal: "role:FINANCE_ANALYST"
      permissions: [read, select]

    - principal: "role:TRADER"
      permissions: [read, select, query]

    - principal: "role:DATA_ENGINEER"
      permissions: [write, insert, update, delete, create]

    - principal: "user:looker_service@company.example.com"
      permissions: [read, select]

# ── Expose: Snowflake Table ───────────────────────────────────
exposes:
  - exposeId: bitcoin_prices_table
    title: "Bitcoin Real-time Price Feed"
    version: "1.0.0"
    kind: table

    binding:
      platform: snowflake
      format: snowflake_table
      location:
        account: "{{ env.SNOWFLAKE_ACCOUNT }}"
        database: "CRYPTO_DATA"
        schema: "MARKET_DATA"
        table: "BITCOIN_PRICES"
      properties:
        cluster_by: ["price_timestamp"]

    policy:
      classification: Internal
      authn: custom

    # Schema contract
    contract:
      schema:
        - name: price_timestamp
          type: TIMESTAMP
          required: true
          description: UTC timestamp when price was recorded
          sensitivity: cleartext
          semanticType: "timestamp"

        - name: price_usd
          type: NUMBER(18,2)
          required: true
          description: Bitcoin price in USD
          sensitivity: cleartext
          semanticType: "currency"

        - name: price_eur
          type: NUMBER(18,2)
          required: false
          description: Bitcoin price in EUR

        - name: price_gbp
          type: NUMBER(18,2)
          required: false
          description: Bitcoin price in GBP

        - name: market_cap_usd
          type: NUMBER(20,2)
          required: false
          description: Total market capitalization in USD
          sensitivity: internal

        - name: volume_24h_usd
          type: NUMBER(20,2)
          required: false
          description: 24-hour trading volume in USD
          sensitivity: internal

        - name: price_change_24h_pct
          type: NUMBER(10,4)
          required: false
          description: 24-hour price change percentage

        - name: last_updated
          type: TIMESTAMP
          required: false
          description: Timestamp from CoinGecko API

        - name: ingestion_timestamp
          type: TIMESTAMP
          required: true
          description: When data was ingested into our system

# ── Build: API Ingestion ──────────────────────────────────────
builds:
  - id: bitcoin_price_ingestion
    description: Fetch Bitcoin prices from CoinGecko API
    pattern: hybrid-reference
    engine: python
    repository: ./runtime
    properties:
      model: ingest
    execution:
      trigger:
        type: manual
        iterations: 1
        delaySeconds: 3
      runtime:
        platform: snowflake
        resources:
          warehouse: "COMPUTE_WH"
          warehouse_size: "X-SMALL"
      retries:
        count: 3
        backoff: exponential
    outputs:
      - bitcoin_prices_table

Key Schema Patterns

The binding schema uses three fields to identify platform resources:

This is identical to GCP (platform: gcp, format: bigquery_table) and AWS (platform: aws, format: parquet).

Column types

CLI Commands

Every normal Snowflake provider command is autodetected from binding.platform, so --provider snowflake is not required for plan, apply, verify, or test.

# Validate Snowflake connectivity with the same config the provider uses
fluid auth status snowflake

# Validate contract shape
fluid validate contract.fluid.yaml

# Generate execution plan
fluid plan contract.fluid.yaml --env dev --out plans/plan-dev.json

# Deploy database, schema, table, and build logic
fluid apply contract.fluid.yaml --env dev --yes

# Verify the deployed Snowflake object against the contract schema
fluid verify contract.fluid.yaml --strict

# Optional: run the live contract test flow
fluid test contract.fluid.yaml

# Validate governance declarations
fluid policy-check contract.fluid.yaml

# Compile access bindings from accessPolicy grants (see the caveat below)
fluid policy-compile contract.fluid.yaml --env dev --out runtime/policy/bindings.json

# Generate Airflow DAG
fluid generate-airflow contract.fluid.yaml --output airflow-dags/bitcoin_snowflake.py

Recommended deployment gate for enterprise teams:

1. fluid validate
2. fluid plan
3. fluid policy-check
4. fluid apply
5. fluid verify --strict
6. optional fluid test

Grant the contract's roles with your own Snowflake tooling until the grants are applied (see Snowflake-Native Security).

Every Snowflake session opened through the provider carries a QUERY_TAG so statements can be attributed in Snowflake QUERY_HISTORY. In practice this means plan/apply/verify traffic can be traced back to the contract and environment that issued it.

RBAC Policy Compilation

fluid policy-compile reads accessPolicy.grants and writes one binding per grant and expose:

{
  "bindings": [
    {
      "provider": "snowflake",
      "resource_type": "snowflake.table",
      "resource_id": "CRYPTO_DATA.MARKET_DATA.BITCOIN_PRICES",
      "database": "CRYPTO_DATA",
      "schema": "MARKET_DATA",
      "table": "BITCOIN_PRICES",
      "principal": "role:DATA_ANALYST",
      "grants": [
        "SELECT"
      ]
    },
    ...
    {
      ...
      "principal": "role:DATA_ENGINEER",
      "grants": [
        "INSERT",
        "UPDATE",
        "DELETE",
        "SELECT"
      ]
    },
    ...

The permission mapping:

No USAGE on the database or schema is compiled.

Governance Scope

Use the governance commands this way:

• fluid policy-check validates governance declarations in the contract.
• fluid policy-compile lists the grants accessPolicy asks for; as of 0.18.1 neither fluid policy-apply nor fluid apply applies them on Snowflake.
• fluid apply writes the table's COMMENT: the contract description, a FLUID classification section (fluid_layer, fluid_product_type, fluid_domain, fluid_version) and the contract YAML.
• fluid verify checks deployed schema and drift. It does not audit grants.

Credentials Setup

Accepted SNOWFLAKE_ACCOUNT Formats

Forge accepts the common Snowflake account identifier formats that teams usually copy from the Snowflake UI, connector docs, or browser URL and normalizes them before opening the connection.

Accepted examples:

• org-account
• xy12345
• xy12345.eu-central-1
• xy12345.eu-central-1.aws
• xy12345.eu-central-1.privatelink
• https://xy12345.eu-central-1.aws.snowflakecomputing.com
• https://app-org-account.privatelink.snowflakecomputing.com

Normalization rules:

• strips https:// and .snowflakecomputing.com
• strips cloud suffixes such as .aws, .gcp, and .azure
• preserves .privatelink when it is part of the effective account identifier
• strips the leading app- prefix from Snowsight-style browser hostnames

Invalid hostnames such as https://example.com fail fast with a validation error instead of being silently misparsed.

Error: the account field requires the "PROVIDER_CONFIGURATION_ACCOUNT_FALLBACK"
experiment to be enabled; add it to experimental_features_enabled

export SNOWFLAKE_ORGANIZATION_NAME=myorg
export SNOWFLAKE_ACCOUNT_NAME=myaccount

Jenkins CI (Recommended)

Create a Jenkins Secret File credential containing your Snowflake env vars:

# File contents (plain key=value, no 'export' prefix)
SNOWFLAKE_ACCOUNT=myorg-myaccount
SNOWFLAKE_USER=FLUID_SERVICE
SNOWFLAKE_PASSWORD=xxxxxxxxxx
SNOWFLAKE_WAREHOUSE=COMPUTE_WH
SNOWFLAKE_ROLE=SYSADMIN
SNOWFLAKE_DATABASE=CRYPTO_DATA
SNOWFLAKE_SCHEMA=MARKET_DATA

The Universal Pipeline auto-detects this format and sources it into every stage. No provider-specific credential logic.

Local Development

# .env file (same format as Jenkins)
cat > .env << 'EOF'
SNOWFLAKE_ACCOUNT=myorg-myaccount
SNOWFLAKE_USER=FLUID_SERVICE
SNOWFLAKE_PASSWORD=xxxxxxxxxx
SNOWFLAKE_WAREHOUSE=COMPUTE_WH
SNOWFLAKE_ROLE=SYSADMIN
SNOWFLAKE_DATABASE=CRYPTO_DATA
SNOWFLAKE_SCHEMA=MARKET_DATA
EOF

# Source and run
set -a; . .env; set +a
fluid auth status snowflake
fluid plan contract.fluid.yaml --env dev --out runtime/plan.json
fluid apply contract.fluid.yaml --env dev --yes
fluid verify contract.fluid.yaml --strict

Session Context Initialization

After connecting, Forge pins the active Snowflake session explicitly using any configured role, warehouse, database, and schema:

USE ROLE <role>;
USE WAREHOUSE <warehouse>;
USE DATABASE <database>;
USE SCHEMA <schema>;

This keeps runtime behavior aligned with the contract and credential settings across local runs, CI, and automation. If any configured value is invalid, Forge fails fast instead of leaving the session half-initialized.

DATABASE and SCHEMA settings may be dot-qualified when Snowflake accepts that shape, for example ANALYTICS.RAW.

Infrastructure Created

When you run fluid apply on the contract above, the OpenTofu module creates three resources (fluid generate iac shows the same module). The warehouse named in execution.runtime.resources must already exist; it is used, not created.

Governance Features

Data Sovereignty

The sovereignty block enforces region restrictions before any infrastructure is deployed:

sovereignty:
  jurisdiction: "EU"
  allowedRegions: [eu-west-1, eu-central-1, europe-west4]
  deniedRegions: [us-east-1, us-west-2, us-central1]
  crossBorderTransfer: false
  regulatoryFramework: [GDPR]
  enforcementMode: advisory  # or strict (blocks deployment)

Column restrictions, masking and row filters are not read

These fields validate on a Snowflake expose and produce nothing on Snowflake as of 0.18.1:

• policy.authz.columnRestrictions
• policy.privacy.masking
• policy.privacy.rowLevelPolicy
• sensitivity: pii on a column

Neither the Snowflake OpenTofu module nor the Snowflake provider reads them, so no masking policy, row access policy or grant comes from them. Do not rely on them to protect a Snowflake column. On GCP, columnRestrictions becomes policy tags; masking at landing is applied by the DuckDB acquisition runner when it writes a local file, an S3 object or a BigQuery load file.

Snowflake-Native Security

What 0.18.1 does with each governance field on a Snowflake binding:

The Snowflake module can emit snowflake_masking_policy, snowflake_row_access_policy and snowflake_grant_privileges_to_account_role objects, but only from a top-level security: block (security.policies, security.access_control.grants). The contract schema rejects that block, so a contract carrying it fails fluid validate, and even then the policies are created without being attached to a column or table.

CI/CD Pipeline

The Snowflake example uses the exact same Jenkinsfile as GCP and AWS — the Universal Pipeline. Key stages:

Snowflake Table Properties

The Snowflake module reads one table property from binding.properties:

binding:
  platform: snowflake
  format: snowflake_table
  location:
    database: "ANALYTICS"
    schema: "MARTS"
    table: "CUSTOMER_METRICS"
  properties:
    cluster_by: ["customer_id", "order_date"]   # must be a list of columns

Other keys under binding.properties (table_type, data_retention_time_in_days, change_tracking) pass validation and are not emitted. Set them on the table with your own tooling.

Iceberg Tables via dbt (since 0.13.1)

An expose with binding.format: iceberg on platform: snowflake closes the dbt Iceberg loop in two halves:

• fluid generate transformation emits dbt's catalogs.yml (v1 catalogs schema, Snowflake adapter) into the generated project. External catalogs (location.catalog: glue, polaris, unity, rest, nessie) map to catalog_type: iceberg_rest; anything else — including no location.catalog at all — is Snowflake-managed (Horizon) and maps to built_in.
• fluid apply provisions the prerequisites dbt refuses to create: the EXTERNAL VOLUME for Snowflake-managed catalogs (needs an s3:// or gs:// location.warehouse, plus location.iam_role_arn for S3), and the AWS Glue CATALOG INTEGRATION for location.catalog: glue (needs location.iam_role_arn — the role Snowflake assumes — and location.account, the AWS account id).

exposes:
  - exposeId: orders_iceberg
    kind: table
    binding:
      platform: snowflake
      format: iceberg
      location:
        database: "ANALYTICS"
        schema: "MARTS"
        table: "ORDERS_ICEBERG"
        warehouse: "s3://analytics-lake/warehouse/"   # storage behind the EXTERNAL VOLUME
        iam_role_arn: "arn:aws:iam::123456789012:role/snowflake-iceberg"

Both halves derive names through one deterministic naming helper, so the EXTERNAL VOLUME fluid apply creates carries exactly the name catalogs.yml references (FLUID_<PRODUCT_ID>_VOL, folded from the contract id). To use a volume your Snowflake admin already created, set binding.icebergConfig.properties.external_volume (camelCase externalVolume is also accepted): catalogs.yml then references your volume and fluid apply emits no CREATE, so apply never collides with the operator-owned object.

Since 0.14.0, fluid validate errors when an Iceberg expose is missing one of the required inputs above instead of letting the emitters silently skip it — see Iceberg prerequisite checks. CI note: under --strict, Snowflake catalogs that authenticate with secrets (polaris / unity / rest / nessie) now fail validation, because the emitted OpenTofu module is credential-free.

See Also

• Snowflake Team Collaboration Walkthrough - Role-based PR review example for Snowflake teams
• Universal Pipeline — Same Jenkinsfile for every provider
• AWS Provider — Amazon Web Services integration
• GCP Provider — Google Cloud Platform integration
• CLI Reference — Full command documentation