Feature flags for teams running on Snowflake

Snowflake should measure a feature flag's effect, not sit in the request path that decides its value.

Teams sometimes picture “feature flags in Snowflake” as a lookup table queried for every request. That creates the wrong architecture for most products. A warehouse is designed for analytical workloads, not millisecond availability decisions across browsers, mobile apps, APIs, and edge services.

Use a feature flag control plane and SDK to deliver definitions and evaluate rules close to the application. Send exposure events and product outcomes through your normal pipeline to Snowflake. Then use governed warehouse facts to answer whether the release improved conversion, retention, reliability, or revenue.

This separation gives each system a job it is good at: low-latency runtime control in the application tier; durable, joinable measurement and audit data in Snowflake.

Separate flag delivery from warehouse analysis

The runtime path has four parts:

1. A control plane stores flag definitions, targeting, environments, and revisions.
2. SDKs fetch or receive those definitions.
3. The SDK evaluates a flag for the current context.
4. A tracking hook records exposure when the result can affect behavior.

GrowthBook's feature flag documentation describes typed flags, targeting rules, percentage rollouts, and experiments. Its SDKs use local evaluation, so an application does not need a network request for each flag decision after definitions are available.

Snowflake enters after the decision. Exposure and outcome events land in raw tables, transformations standardize them, and experiment or rollout metrics query curated models.

Do not use a Snowflake row as a request-time toggle

Polling a warehouse table from production services creates avoidable latency, connection, caching, and outage problems. It also pushes rule evaluation into application-specific SQL, where different services can interpret the same flag differently.

If internal batch jobs run entirely inside Snowflake, a configuration table may legitimately control a scheduled model. Name it remote configuration or job parameters unless it follows the same ownership, targeting, audit, and cleanup process as product flags.

Define a trustworthy exposure event

A flag evaluation is not always an exposure. A backend can evaluate several branches before choosing one, or a UI can evaluate a flag for a component that never renders. Logging every evaluation may inflate enrollment.

Record the first moment the assigned behavior can affect the unit. Include:

• feature key and experiment ID when applicable;
• variation value or ID;
• randomization-unit ID;
• exposure timestamp;
• environment and application source;
• feature-definition or assignment revision;
• SDK name and version where operationally useful.

Use the same logical event for control and treatment. GrowthBook's tracking callback is the boundary where applications can send experiment exposures into an existing event pipeline.

Keep the randomization ID joinable

If the flag randomizes by account, Snowflake metrics must resolve to account. If anonymous visitors later authenticate, preserve the bridge without duplicating exposure or moving a subject between variations.

The experimental-unit guide explains why analysis must aggregate at the independently assigned unit. A warehouse join cannot repair a mismatch between user-level delivery and account-level interference.

Model flags and outcomes in Snowflake

Create a narrow canonical exposure view and keep raw events for replay.

CREATE OR REPLACE VIEW EXPERIMENT_ANALYTICS.FLAG_EXPOSURES AS
SELECT
  FEATURE_KEY,
  EXPERIMENT_ID,
  VARIATION_ID,
  SUBJECT_ID,
  EXPOSED_AT,
  ENVIRONMENT,
  DEFINITION_REVISION
FROM RAW.FLAG_EXPOSURE_EVENTS
WHERE ENVIRONMENT = 'production'
QUALIFY ROW_NUMBER() OVER (
  PARTITION BY FEATURE_KEY, EXPERIMENT_ID, SUBJECT_ID
  ORDER BY EXPOSED_AT
) = 1;

Create a separate diagnostic for subjects seen in multiple variations. Do not let the deduplication view silently turn identity instability into apparently clean data.

Outcome facts should use stable keys and times: completed orders, successful activations, error events, latency observations, retention states, and support contacts. GrowthBook fact tables can supply reusable metric sources rather than embedding one-off SQL in every rollout.

Keep feature flags maintainable

Build ownership, lifecycle, rollout, and cleanup practices that continue to work as teams and environments multiply.

Read the Scaling Guide

Use flags for controlled delivery

A release flag can progress through internal users, a named pilot cohort, a small percentage, and broader rollout. Treat each environment and step as an explicit change with an owner, expected impact, monitoring window, and rollback condition.

Choose targeting attributes available at decision time

Use stable, privacy-reviewed attributes such as plan, region, app version, or account ID. Do not target on outcomes observed later. Define missing-attribute behavior, and test rules against fixtures before publishing.

The vendor-neutral OpenFeature specification provides a consistent evaluation API and context model. It can reduce provider-specific code, but teams still need a shared contract for attribute names and types across SDKs.

Make fallback behavior explicit

Test application startup without definitions, a stale cache, invalid JSON, credential failure, and interrupted updates. A safe default is feature-specific: control for a new checkout, a protective state for an operational kill switch, and a defined entitlement policy for paid access.

Snowflake is not the runtime fallback. It is where you later verify that the failure path produced the intended operational and customer outcomes.

Turn a flag rollout into an experiment carefully

A gradual rollout answers “Can we deliver this safely?” An A/B test answers “What did this change cause?” The same flag can support both, but only when assignment is randomized and the analysis is planned.

Before launching an experiment, define population, unit, variations, primary metric, guardrails, minimum meaningful effect, attribution window, and stopping rule. GrowthBook's A/B test design guide provides that prelaunch structure.

Connect the Snowflake exposure view and outcome facts to GrowthBook's warehouse-native experimentation. Review generated SQL, verify returned columns and time zones, and reconcile enrollment against direct Snowflake queries.

Run an A/A phase when the flag-to-Snowflake integration is new. Check expected allocation, multiple variation exposure, null identifiers, join rates, pre-treatment metrics, and metric freshness. GrowthBook's sample ratio mismatch checks can flag suspicious allocation before lift is interpreted.

Govern Snowflake access and compute

Use a dedicated Snowflake role with usage on one analysis warehouse and select on curated models only. Avoid exposing raw payloads or unrelated customer attributes.

Snowflake's access-control overview details role hierarchies and object privileges. Test access as the actual service role and use key-pair or federated authentication with rotation.

Run experiment analysis on a separate virtual warehouse. Snowflake virtual warehouses provide independent compute for queries, which creates a cost and performance boundary from ingestion and transformation.

Set auto-suspend and resource monitors, and tag queries so owners can be identified. Snowflake's 0 parameter can attach experiment, application, and environment metadata visible in query history.

Control scan volume by filtering exposure and outcome windows early, projecting required columns, and aggregating to the randomization unit before wide joins. Promote commonly used fields out of semi-structured payloads. Materialize stable expensive transformations when the compute savings justify freshness and maintenance cost.

Inspect pruning rather than assuming a date predicate is sufficient. Snowflake's micro-partition documentation explains how metadata and clustering affect which partitions a query can skip; use query profiles to decide whether a large exposure or event model needs a different physical design.

Monitor both release safety and product impact

Operational rollout monitoring needs faster signals than a mature experiment metric. Track evaluation errors, definition freshness, service latency, application errors, saturation, and rollback status in operational systems.

Snowflake supplies deeper outcome measurement. Define primary, secondary, and guardrail experiment metrics from canonical facts. Display the warehouse cutoff and maturity window so decision-makers do not treat partial retention or revenue as final.

A practical sequence is:

Close the feature flag lifecycle

Every flag needs an owner, type, creation date, expected end state, and removal condition. When a release reaches 100%, the flag is not finished. Remove the losing path, delete dead tests, update documentation, and then archive the control-plane flag after verifying the permanent behavior.

Keep an analytical record in Snowflake: exposure dates, variation definitions, metric versions, result, decision, and cleanup reference. That history helps teams avoid rerunning old ideas and diagnose interactions with later releases.

Feature flags and Snowflake complement each other when their responsibilities stay clear. The flag system makes a fast deterministic runtime decision. Snowflake connects that decision to trusted business outcomes. A warehouse-native experimentation layer turns the connection into an auditable causal result.

Design rollback evidence before a rollout begins

A rollback is a runtime action, but Snowflake supplies the evidence for whether it worked. Log the flag version, evaluated variation, unit ID, environment, exposure time, request or trace identifier, and the operational signals available at the decision boundary. Do not wait for a failed release to discover that exposures cannot be joined to errors or orders.

Define two classes of threshold. Runtime thresholds such as error rate, timeout rate, or saturation can trigger an immediate pause without statistical inference. Product thresholds such as conversion or retention usually need a planned experiment window and uncertainty estimate. Mixing them encourages teams either to wait too long during incidents or to overreact to noisy business data.

After a rollback, preserve the phase boundaries. A user exposed before and after the change may have mixed treatment, and a simple final-variation label can erase that history. Analyze clean phases separately or use a method designed for time-varying exposure.

Audit the control plane and the warehouse together. A flag-change record should identify who changed traffic, why, and which version was active; Snowflake should show the resulting exposure population and health metrics. Periodically reconcile both systems. That shared record makes incident review, experiment interpretation, and eventual flag removal much more reliable.

Isolate the Snowflake analysis service

Give the warehouse integration a dedicated service user, role, compute warehouse, and query tag. Grant read access to approved exposure and metric views, not broad production schemas. If temporary results are required, confine writes to a tool-specific schema with an explicit retention policy.

Tune the warehouse from observed workloads. Start small, enable auto-suspend, and measure queue time, elapsed time, bytes scanned, cache use, and credits across concurrent refreshes. A larger warehouse may finish sooner without costing less. Use a resource monitor and alert before experiment queries interfere with shared workloads.

Every result should display a source cutoff and transformation freshness. If exposure ingestion is current but revenue is delayed, the combined analysis is delayed. Query and task failures should mark results stale rather than silently retaining a partially updated variation.

Rotate credentials and change a test schema before production. Confirm that the connection fails visibly, preserves its least-privilege boundary, and recovers without leaving orphaned temporary objects. The operating proof is as important as the statistical one.

Publish an acceptance record for each phase

Internal rollout should prove targeting and instrumentation. A small ramp should prove stable allocation and runtime safety. The experiment phase should prove a causal product effect. The final ramp should prove the winning behavior remains safe at broader load. Record which evidence cleared each gate.

Include flag and definition versions, Snowflake source cutoff, first-exposure counts, crossovers, metric versions, health checks, effect estimates, approver, and action. If a phase fails, preserve the failure and corrective change instead of overwriting it with the next configuration.

This phase record connects the fast-changing control plane to slower warehouse evidence and gives cleanup reviewers confidence that the remaining branch is intentional.

Review active flags and their Snowflake dependencies regularly. Remove unused grants, stale metric models, orphaned result tables, and overdue temporary flags. Sample a completed rollout and reproduce its exposure counts and decision metrics from the retained versions. This maintenance is what keeps a mature system trustworthy after the initial integration team moves on.

Connect Snowflake to every rollout

Use local feature evaluation and warehouse-native metrics in one workflow for controlled releases and rigorous experiments.

Start Building Free