Snowflake Guide

What and why

Snowflake is our Enterprise Data Warehouse (EDW) and is the core technology in our Enterprise Data Platform.

What does Snowflake Contain?

Snowflake contains all of our analytical data and Data Sources defines the set of original/raw data available.

Related Content

• Access
• Support Portal Access
• Compute Resources
• Data Masking
• Backups
• AI Function Guide

Current access model

Snowflake access operates on a hybrid model depending on your account history and the level of access required.

Current access architecture

Snowflake access at GitLab is split across multiple systems working together:

• Lumos serves as the request and approval solution for Snowflake access.
• Okta SCIM creates or updates Snowflake users when Lumos requests are approved, assigning (wrapper) roles:
  • SNOWFLAKE_ANALYST_OKTA (which inherits the underlying SNOWFLAKE_ANALYST role)
  • SNOWFLAKE_ANALYST_SAFE_OKTA (which inherits the underlying SNOWFLAKE_ANALYST_SAFE role)
• Permifrost remains the source of truth for all custom, team-specific, and extended Snowflake authorization beyond the baseline analyst roles. This includes functional roles (e.g., analyst_marketing) and dev database access. This can be requested either via Lumos (Customer User) or via an Access Request.
• Snowflake SSO: provides the login tile and SSO access.

The Okta SCIM path is intended only for the two access levels: Analyst and Analyst SAFE. Anything beyond these two roles is managed through the Permifrost process.

Where Okta SCIM stops

The Okta SCIM provisioning path is designed for the two baseline access levels only: Analyst and Analyst SAFE.

1. Pre-SCIM users: If your Snowflake account existed before Okta SCIM was implemented, Okta SCIM will not provision your account.
2. Custom or extended roles: If you need team-specific roles (e.g., analyst_marketing), functional roles (e.g., analyst_core), or dev database access, those are managed separately through the Permifrost process.
3. Mixed-role users: Users who have both Lumos-managed baseline roles and Permifrost-managed custom roles exist in both systems. Lumos and Permifrost are separate layers and do not automatically mirror each other.

Logging In

Login to Snowflake from Okta.

Navigating the UI

The Snowflake Quick Tour of the Web Interface provides comprehensive documentation for the UI.

Snowflake account configuration

ABORT_DETACHED_QUERY

ABORT_DETACHED_QUERY parameter is set on account level to True.

We often have cases where the connectivity was lost and the query keeps trying to run and still does not complete. It is meaningless for the query to keep running in these cases and adds no value. There is a grace period of 5 minutes. If the connectivity isn’t fixed in 5 minutes, it stops the execution so the warehouses won’t be running unnecessarily.

Data Freshness

We leverage automatic monitors in MonteCarlo for monitoring the freshness of the data.

Snowflake Warehouse Sizing Guide

Key principles

1. Start with XS by default for all development work across all environments (Snowsight, Tableau, local dbt development, etc.). Only size up when a specific query or workflow requires it and subsequently size-down afterwards.

2. Key signal for over-provisioning: If your queries run on a warehouse larger than XS but complete in under 30 seconds, you’re likely wasting credits.

Warehouse Sizing Quick Reference

Note:

• Row count ranges are extremely rough guidelines that often overestimate warehouse size. A 3B-row table filtered to 1 week may only need XS, not M. We provide them only as a quick starting reference.
• For more accurate sizing, use partitions_scanned (ranges provided by Snowflake Solutions Architects), visible via the explain command, i.e explain select * from my_table where my_filter;

Decision Framework: When to Size Up

For a more accurate warehouse selection, please consider the following 3 variables:

1. Table Size (Starting Point)

SELECT COUNT(*) FROM your_table;

2. Filter Selectivity (Can You Stay Smaller?)

3. Query Complexity (Need More Power?)

Real Examples: mart_behavior_structured_event

These examples show that even for one of our largest tables, a XS can be sufficient:

-- 51 seconds on DEV_XS
-- No LIMIT, but highly filtered time range (3 days)
SELECT *
FROM PROD.COMMON_MART.MART_BEHAVIOR_STRUCTURED_EVENT
WHERE BEHAVIOR_AT BETWEEN '2025-01-01' AND '2025-01-03'
  AND event_action = 'check_policy_scope_for_security_policy'
  AND app_id = 'gitlab';

-- 49 seconds on DEV_XS
-- Aggregation with moderate time range
SELECT
    event_action,
    COUNT(*) AS ct
FROM PROD.COMMON_MART.MART_BEHAVIOR_STRUCTURED_EVENT
WHERE BEHAVIOR_AT BETWEEN '2025-02-01' AND '2025-02-15'
GROUP BY ALL
HAVING ct > 50
ORDER BY ct DESC;

-- 71 seconds on DEV_M
-- Joins 2TB fact table (filtered) with 260GB dimension (unfiltered)
SELECT *
FROM prod.common.fct_behavior_website_page_view fct
JOIN prod.common.dim_behavior_website_page dim
  ON fct.dim_behavior_website_page_sk = dim.dim_behavior_website_page_sk
WHERE behavior_at >= CURRENT_DATE - 7
  AND dim.app_id = 'docs'
LIMIT 10000;

VS Code Snowflake extension

To use Snowflake from VS Code, install the Snowflake Extension for Visual Studio Code from the Extensions pane.

Setup:

1. First, confirm you can log into the Snowflake UI via Okta in the browser.
2. Click the Snowflake icon in the VS Code left sidebar and sign in with the following:
   • Account Identifier: gitlab
   • Auth Method: Single sign-on
   • Username: your full GitLab email
3. Click Sign in — an Okta window will open. Complete SSO and return to VS Code.

Once connected, use the dropdowns in the Snowflake panel to set your role and warehouse.

From there, open any .sql file in VS Code and run queries directly without touching the web UI.

View page source - Edit this page - please contribute.