Feature flags for teams running on Redshift

Feature flags should make fast decisions in your applications. Redshift should measure whether those decisions helped.

Amazon Redshift is a strong home for the evidence behind a rollout: exposure history, product events, orders, accounts, reliability facts, and long-term outcomes. It is not designed to answer a flag lookup for every web or API request.

Use a control plane and SDK to distribute versioned definitions and evaluate locally or through a low-latency service. Send exposure and outcome events through your normal data path. Then let Redshift join those facts, calculate metrics, and support experiment analysis.

This division preserves runtime reliability while using the warehouse as the source of truth for product impact.

Give each flag an explicit job

Classify flags when they are created:

• release flags separate deployment from customer release;
• operational flags disable or reroute risky behavior;
• experiment flags create randomized treatments;
• entitlement flags represent durable product access;
• remote configuration provides typed runtime values.

Each type needs an owner, default, environments, intended lifetime, approval path, and cleanup condition. GrowthBook's feature flag platform supports typed values, targeting, gradual rollouts, approvals, and experiments. Its feature flag best-practices guide explains why lifecycle discipline is as important as initial delivery.

Evaluate outside Redshift

Applications should consume cached definitions and evaluate from context available before the decision. Test cold starts, definition refresh failure, malformed rules, network loss, and recovery. The safe fallback differs by feature.

GrowthBook's SDK documentation describes local feature evaluation. The OpenFeature specification provides a vendor-neutral API and provider model for teams that want a stable application abstraction.

Send exposure evidence into Redshift

Log an exposure when the assigned value can first influence the subject—not every time code asks for the value. Use the same logical point for every variation.

The event should contain:

{
  "feature_key": "recommendation-ranker",
  "experiment_id": "ranker-v3",
  "variation_id": "candidate",
  "subject_id": "account_987",
  "exposed_at": "2026-09-09T18:42:11Z",
  "environment": "production",
  "definition_revision": "rev_18"
}

Preserve the exact randomization ID. If assignment occurs by account, analyze account-level outcomes. The experimental-unit guide covers why counting correlated users or events as independent creates false precision.

Batch delivery is often sufficient for experiment analysis. If exposure freshness truly needs seconds, Amazon Redshift streaming ingestion can consume from Kinesis Data Streams or Amazon MSK into materialized views. Define deduplication, replay, schema, refresh, and late-event behavior before relying on it.

Keep release flags under control

Add ownership, rollout stages, and cleanup rules that work across teams, environments, and services.

Read the Scaling Guide

Build a canonical Redshift exposure model

Keep raw append-only events, then make one analyzable first exposure per subject and experiment.

CREATE OR REPLACE VIEW experiment_analytics.flag_exposures AS
SELECT feature_key, experiment_id, variation_id,
       subject_id, exposed_at, environment, definition_revision
FROM (
  SELECT
    feature_key, experiment_id, variation_id,
    subject_id, exposed_at, environment, definition_revision,
    ROW_NUMBER() OVER (
      PARTITION BY feature_key, experiment_id, subject_id
      ORDER BY exposed_at
    ) AS exposure_rank
  FROM raw.flag_exposure_events
  WHERE environment = 'production'
) ranked
WHERE exposure_rank = 1;

Create a separate data-quality query for subjects seen in multiple variations. Do not let the view silently conceal unstable identity or experiment restarts.

Model outcomes as reusable facts rather than parsing raw payloads in every result query. GrowthBook fact tables support shared conversion, revenue, retention, and guardrail metrics.

Ship through controlled stages

Begin with internal subjects, then a named pilot and small stable percentage. Define operational rollback signals before increasing traffic. A wider randomized phase can measure impact when the question is causal.

An ordinary rollout answers whether the system can deliver safely. An A/B test estimates what the change caused. The latter requires concurrent randomized assignment, symmetric exposure, one analysis unit, and predeclared metrics and stopping rules.

GrowthBook's feature flag experiments attach experiment behavior to a flag. Its warehouse-native architecture can query Redshift models for outcome analysis.

Measure one row per randomized unit

WITH enrolled AS (
  SELECT subject_id, variation_id, exposed_at
  FROM experiment_analytics.flag_exposures
  WHERE experiment_id = :experiment_id
    AND exposed_at >= :phase_start
    AND exposed_at < :phase_end
),
unit_metric AS (
  SELECT
    e.variation_id,
    e.subject_id,
    MAX(CASE WHEN o.completed_at >= e.exposed_at
              AND o.completed_at < DATEADD(day, 7, e.exposed_at)
             THEN 1 ELSE 0 END) AS converted
  FROM enrolled e
  LEFT JOIN commerce.orders o ON o.account_id = e.subject_id
  GROUP BY e.variation_id, e.subject_id
)
SELECT variation_id, COUNT(*) AS units,
       SUM(converted) AS conversions,
       AVG(converted::decimal(18, 8)) AS conversion_rate
FROM unit_metric
GROUP BY variation_id;

Use bound parameters and a mature observation cutoff. Production analysis also needs uncertainty, multiple-metric controls, and declared outlier and sequential-monitoring behavior. GrowthBook's metric framework supplies a reusable analysis layer.

Isolate the Redshift workload

Repeated experiment refreshes can compete with transformations and dashboards. Amazon Redshift workload management can classify queries, assign priority, and apply monitoring rules. Put the experimentation role or query group in a visible class.

For stronger isolation, Redshift data sharing can expose live governed objects to another cluster or Serverless workgroup without manually copying the data. This creates independent compute and chargeback while preserving the producer as source.

Pre-aggregate repeated unit-level facts. Redshift materialized views can store expensive joins and aggregations, but freshness must be visible to decision-makers.

Monitor queue time, execution time, spill, scanned rows, and aborted queries. Community debate about Redshift workload fit is useful as a reminder that operational outcomes depend on data model, scale, and ownership—not the warehouse name alone.

Grant limited access

Use a dedicated identity with schema usage and select on approved exposure, fact, and dimension views. Do not use an administrator or a role that can modify raw facts. Require encrypted transport and managed credential rotation.

If analysis runs in a data-sharing consumer, expose only the objects required. AWS documents views in Redshift data sharing, including support differences between regular, late-binding, and materialized views.

Test every generated query under the final principal and workload route. A successful admin query does not validate production access.

Validate before interpreting lift

Check expected allocation, multiple-variation exposure, null IDs, phase dates, joins by arm, pre-treatment metrics, ingestion lag, and materialized-model freshness. GrowthBook's sample ratio mismatch check surfaces suspicious allocation that requires investigation.

An A/A phase is especially useful for a new SDK-to-stream-to-Redshift path. It exercises real assignment, event transport, transformations, and analysis. Keep treatment-specific QA for rendering, application errors, and exposure symmetry.

At the decision point, compare the primary estimate and interval with a minimum meaningful effect and review guardrails. Record the definition revision, metric version, data cutoff, query identity, decision, and owner.

When rollout reaches 100%, remove the losing branch and associated tests, verify permanent behavior, and archive the flag. Redshift should retain enough evidence to explain the decision later, but dead runtime code should not remain indefinitely.

The successful pattern is deliberately asymmetric: flags are fast and close to the application; measurement is deep and close to the warehouse. Connecting them creates controlled delivery without turning Redshift into a runtime dependency.

Reconcile every rollout phase in Redshift

For internal, percentage, experiment, ramp, and completed phases, compare the configured allocation with first exposures observed in the warehouse. Break counts down by variation, SDK version, environment, platform, region, and hour. This distinguishes a control-plane mistake from stale configuration, incomplete ingestion, or a client-specific bug.

Store the definition or configuration version on the exposure record. A current flag value cannot explain what a user received last week. Preserve raw evaluations for debugging, but build one canonical first-exposure model per randomization unit and phase. Report cross-variation units rather than hiding them with a final-value join.

The exposure boundary should be symmetric. If treatment logs only after a new component renders while control logs during an earlier flag check, treatment users have already passed an extra condition. Move logging to the shared decision boundary or redesign the analysis population.

Design the Redshift workload as a service

Route experiment jobs through an explicit workload-management queue or Serverless workgroup. Set concurrency and timeout policies with the data platform owner. A dashboard refresh should enqueue or reuse analysis, not open an unbounded warehouse query for every viewer.

Observe queue time as well as execution time. Use query labels or stable comments to connect jobs with metrics and experiments. Track scanned rows, spill, distribution skew, failures, and output freshness. Repeated scans of the same exposure and identity logic are a sign to create governed intermediate facts.

Materialized views can accelerate repeated work, but they introduce a refresh contract. Store the latest complete source timestamp, handle backfills explicitly, and keep a raw reconciliation query. If a view is stale for one arm's newest exposures, the result should be marked incomplete.

Separate incident thresholds from product inference

An operational flag can roll back immediately when error rate, saturation, or latency exceeds a predefined safety threshold. A product metric such as conversion or retention normally requires a planned observation window and uncertainty estimate. State both policies before ramping traffic.

After an emergency change, preserve phase boundaries and mixed-exposure diagnostics. Do not combine pre-rollback and post-rollback rows under the final variation label. Analyze clean phases or restart the controlled comparison after the system stabilizes.

Rehearse the full path in a non-production environment: disconnect an SDK from configuration, delay the event stream, suspend analysis compute, rotate credentials, and change a source column. Runtime delivery should fall back safely; warehouse analysis should fail visibly and retain the last verified result as stale.

Model identity and outcomes at the assigned unit

If the flag assigns accounts, aggregate user events to one account value before comparing variations. If it assigns users, do not expand the sample size by treating sessions, clicks, or orders as independent. Keep the assigned unit explicit in every exposure and metric model.

Use effective-dated identity mappings. A current account membership table can attach last month's user exposure to today's organization and rewrite historical populations. Preserve membership at exposure or reconstruct it with valid-from and valid-to bounds.

Outcome facts need a time, value, unit, source cutoff, and known grain. Revenue policies should define refunds, currency, taxes, caps, and negative values. Retention metrics should define maturity, while ratios should retain numerator and denominator components at the unit level.

Make changes reviewable

Version flag definitions, exposure models, metric SQL, and materialized transformations. An analyst should be able to explain which versions produced a result after the runtime flag is archived. Add fixtures for no outcome, duplicate exposure, crossover, late event, identity change, and rollback phase.

When a metric definition is corrected, choose explicitly whether historical results are frozen, restated, or shown in both forms. Keep the original decision evidence. This prevents a harmless data-model improvement from making the organization's experiment history internally inconsistent.

Use a rollout acceptance sequence

Before internal traffic, test typed defaults, SDK initialization, cached behavior, targeting, and the exposure payload. Before a percentage ramp, reconcile configured allocation with Redshift first exposures and confirm error, latency, and saturation thresholds.

Before the controlled experiment, freeze the hypothesis, eligible population, randomization unit, primary metric, guardrails, observation window, and analysis method. Run an A/A phase if the delivery-to-warehouse path is new or materially changed.

Before full rollout, review effect size, uncertainty, data health, operational safety, phase contamination, and metric maturity. After rollout, observe the permanent path, remove losing code and temporary tests, then archive the flag. Store the final decision and cleanup reference in the experiment record.

Assign owners to every handoff: application delivery, flag configuration, event transport, Redshift models, analysis, and decision. When an alert fires, that map prevents the team from treating “the experimentation system” as one opaque component.

Review the system quarterly. Remove unused grants and models, rotate credentials, inspect expensive and failed query patterns, sample exposure joins, and reproduce a completed decision. Track flag age, overdue cleanup, crossover rate, data freshness, and the share of experiments stopped for quality problems.

These maintenance signals reveal whether the program is scaling safely. More active flags and faster queries are not success if decision evidence becomes less reproducible or transactional teams lose confidence in the warehouse workload.

Measure Redshift-backed rollouts

Combine local feature evaluation with transparent warehouse metrics for safe releases and rigorous product experiments.

Start Building Free