> For the complete documentation index, see [llms.txt](https://v2.dataos.info/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://v2.dataos.info/build/v1/productize/connect-engine/snowflake.md). # Snowflake Snowflake is a cloud data warehouse for governed, SQL-first enterprise analytics. Use the `snowflake` adapter when your data already lives in Snowflake. This page covers the connection. For materialization internals, tuning, and the full reference, see the [Snowflake engine manual](https://v2.dataos.info/references/engine-guide/snowflake) in References. ## Before you start * A Snowflake account with valid credentials. * A warehouse available for running computations. * DataOS access: a `roles:id:data-dev`-equivalent role tag, `depot:rw:` (or `depot:r` for read-only), **Can Use** on Compute/Depots/Secrets, and a git-sync Secret. Verify with `dataos-ctl user get` and `dataos-ctl get depot`. ## Permissions Snowflake access splits into two grants: read-only on the schemas Vulcan reads, and managed access on the schema where Vulcan writes output. * **Source schemas (read-only)** - grant `USAGE` on the warehouse, database, and schema, and `SELECT` on all and future tables and views. * **Target schema (Vulcan-managed)** - grant `USAGE`, `CREATE TABLE`, `CREATE VIEW`, and `SELECT, INSERT, UPDATE, DELETE, TRUNCATE` on all and future tables. Vulcan needs `DELETE` because it deletes a slice's rows before reinserting refreshed rows during incremental rebuilds, and `TRUNCATE` for full refreshes. Grant `OWNERSHIP` only if DataOS must manage the schema lifecycle (`ALTER`, `REPLACE`, `DROP`). The exact grants also depend on whether source and target share one database or span two: see the [minimum-permissions reference](https://v2.dataos.info/references/resources/vulcan/roles-and-permissions/snowflake-minimum-permissions) for the single-database, cross-database, and semantic-read-only tiers. {% hint style="warning" %} When connecting through a Depot, Vulcan reads the Snowflake `role` from the `role` key in the DataOS secret projection, not from the depot spec. If this project uses a custom role, make sure that key is set in the secret. Otherwise, Vulcan silently falls back to the connection's default role. {% endhint %} ## Connection options | Option | Required | Description | | -------------------------------------------- | :------: | ------------------------------------------------------ | | `type` | Yes | Must be `snowflake` | | `account` | Yes | Account identifier, format `-` | | `user` | Yes | Authentication username | | `password` | Yes | Authentication password | | `warehouse` | Yes | Warehouse for computations | | `database` | Yes | Database to connect to | | `role` | No | Role for authentication | | `authenticator` | No | Method, for example `externalbrowser` or `oauth` | | `token` | No | OAuth 2.0 access token | | `private_key_path`, `private_key_passphrase` | No | Private key authentication | ### Authentication methods * **Key-pair JWT** (recommended for production): set `authenticator: snowflake_jwt`, `private_key_path`, and `private_key_passphrase`. * **Username and password**: set `user` and `password`. * **OAuth 2.0 token**: set `token`. * **External browser SSO**: set `authenticator: externalbrowser`. * **Role-based**: set `role`. ## Example ```yaml gateways: snowflake: connection: type: snowflake account: user: password: "{{ env_var('SNOWFLAKE_PASSWORD') }}" warehouse: database: role: ``` Find the account identifier in your Snowflake URL. ### Using a Depot Snowflake has no local Docker setup, so production connects through a Depot instead of raw credentials: ```yaml gateways: default: connection: type: depot address: dataos://snowflakedepot?purpose=rw ``` A depot is registered with one or more purposes (`rw`, `scan`, `query`): bind the purpose to the credential's actual use; a `query` credential can't create tables, and handing an `rw` credential to a consumer over-permissions them. ## Supported model kinds `FULL`, `SEED`, `VIEW`, `INCREMENTAL_BY_TIME_RANGE`, `INCREMENTAL_BY_UNIQUE_KEY`, `INCREMENTAL_BY_PARTITION`, `MANAGED` (Dynamic Tables, Enterprise and above), and `SCD`. For how each kind materializes, see the [Snowflake engine manual](https://v2.dataos.info/references/engine-guide/snowflake). > Snowflake stores unquoted identifiers in UPPERCASE. Column names in dimensions, measures, filters, and joins must be uppercase, or the warehouse won't resolve them. See the engine manual for the full casing rules. Once `vulcan info` succeeds, continue to [Assets](/build/v1/productize/assets.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://v2.dataos.info/build/v1/productize/connect-engine/snowflake.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.