Skippr Docs

Appearance

What Access Skippr Needs to Write to Snowflake ​

June 2026

Snowflake write access is governed by the role grants, not by whether the user can log in once.

Short Answer ​

Skippr needs valid Snowflake authentication through account and user details, ideally with key-pair auth, plus a role that has the documented warehouse and schema grants. The destination docs list the required role privileges directly: USAGE on the warehouse, USAGE on the database, USAGE and CREATE TABLE on the raw schema, and CREATE SCHEMA on the database for downstream schema creation.

A clean setup often uses a dedicated service account such as skippr_svc with a role like SKIPPR_ROLE, key-pair authentication through SNOWFLAKE_PRIVATE_KEY_PATH, database ANALYTICS, schema RAW, and warehouse COMPUTE_WH. When CDC is enabled, Snowflake uses MERGE-based final-state reconciliation, so those grants support not just initial loads but the ongoing table updates that keep current rows correct.

Why Teams Struggle with This ​

Snowflake access mistakes often happen because login success hides role failure. The service user can authenticate and still lack one of the specific warehouse, database, or schema grants that the first useful run needs to create and maintain managed tables.

  • The configured role needs USAGE on the target warehouse and database.
  • The role also needs USAGE and CREATE TABLE on the raw schema plus CREATE SCHEMA on the database.
  • Key-pair auth is the safer default and is required when MFA blocks password auth.
  • Internal staging usually needs no extra cloud credentials, but if you choose external staging you still have to configure that upload boundary deliberately.

How Skippr Handles It ​

Skippr works well with Snowflake because the access model is explicit in Snowflake terms rather than hidden behind generic warehouse wording. You choose the account, user, role, database, schema, warehouse, and optional staging controls, then grant only the privileges the runtime actually needs.

The CDC destination docs keep the write contract equally concrete. Snowflake uses MERGE for final-state reconciliation and automatically creates _skippr_order_token columns plus tombstone tables, so the role is supporting a durable current-state table model instead of ad hoc cleanup SQL after every load.

  • Supports service-account-friendly Snowflake auth, with key-pair auth recommended.
  • Uses a narrow role grant model centered on warehouse, database, and schema privileges.
  • Does not require extra configuration for the normal internal-stage upload path.
  • Uses Snowflake MERGE with order-token and tombstone protections for CDC-managed tables.

What the First Useful Version Looks Like ​

The first useful version is one dedicated Snowflake role, one raw schema, and one service user whose grants you can explain line by line before the first production load.

If you later switch to external staging, treat that as a new access review because storage integrations and cloud-upload credentials add another boundary beyond the core Snowflake role.