Skippr Docs

Appearance

What Network or Staging Access Snowflake Needs ​

July 2026

Snowflake destination access starts with account, warehouse, role, and schema grants, then adds staging details only if you override the default internal stage flow.

Short Answer ​

Snowflake needs account access, a usable warehouse and role, and the schema-level grants required to create and write the destination tables. The destination docs are very explicit about account, user, database, schema, warehouse, and role, and they also explain an important staging boundary: Skippr uses Snowflake internal staging by default, so most setups do not need extra S3, Azure, or GCS credentials just to get started.

That is the real shape to lead with. If the landing area is ANALYTICS.RAW, the role needs USAGE on the warehouse and database, USAGE plus CREATE TABLE on the raw schema, and CREATE SCHEMA on the database for silver and gold creation. Only when you override the default flow with stage, staging_uri, or a storage integration does the path expand into external staging details such as s3://..., Azure SAS tokens, or a GCS service-account key path.

Why Teams Struggle with This ​

Snowflake setups often feel more complicated than they need to because teams start by debating external staging. The docs point in the opposite direction: start with the internal stage path, confirm the role grants and warehouse access, and only add external staging when there is a real reason.

  • The Snowflake role needs the documented warehouse, database, schema, and create privileges before the first useful load.
  • Key-pair auth or password auth has to match the account policy, especially when MFA is enforced.
  • Internal staging is the default path, so external bucket or blob credentials are not always required.
  • If you do override staging, the object-store credentials and Snowflake integration settings become part of the load path immediately.

How Skippr Handles It ​

Skippr keeps the Snowflake boundary honest by exposing both the core warehouse path and the optional staging controls directly. That lets you explain the normal case clearly: Snowflake account, user, role, warehouse, database, schema, then load. If you need external staging, the extra fields are there without pretending they are mandatory for every deployment.

It also aligns cleanly with the CDC docs. Once the destination is reachable, Skippr uses Snowflake MERGE with _skippr_order_token and tombstones for final-state tables, so the same warehouse path handles both initial landing and reconciled CDC application.

  • Uses Snowflake internal staging by default.
  • Supports optional external staging through stage, staging_uri, and storage integration controls when needed.
  • Requires explicit role grants for warehouse usage, schema writes, and downstream schema creation.
  • Applies CDC through Snowflake MERGE with automatic order-token and tombstone management.

What the First Useful Version Looks Like ​

The first useful version is one Snowflake service user, one role with the documented grants, one warehouse, and one raw schema load using the default internal stage path.

Only add external staging after that is working. Snowflake is easiest to run when the core warehouse boundary is settled before extra storage decisions are introduced.