🔒 Internal - Support Team Only
🗓 Updated: June 2026 | ✍️ Originally created by: Support Team
This article explains the four Snowplow pipeline environments - Production, QA, Snowplow Mini, and Snowplow Micro - to help customers and support engineers understand which environment to use for a given need. In short: Micro and Mini are lightweight developer tools; QA is a full pre-production mirror; Production is the live data pipeline.
Overview
Snowplow provides four distinct environments that serve different stages of the data pipeline lifecycle. Understanding which environment to use - and its limitations - prevents common mistakes such as testing destructive schema changes on Production, or assuming Snowplow Mini provides full warehouse loading capabilities.
| Environment | Primary Purpose | Audience |
|---|---|---|
| Production | Live event collection, enrichment, and warehouse loading at scale | End-to-end data pipeline for real user traffic |
| QA Pipeline | Full pre-production pipeline mirror for end-to-end integration testing | Engineering and data teams before promoting changes to Prod |
| Snowplow Mini | Single-instance developer environment for rapid schema and tracker prototyping | Developers testing schema changes; now superseded by Micro |
| Snowplow Micro | Lightweight local pipeline for unit testing and automated CI/CD test suites | Developers, QA engineers; recommended replacement for Mini |
Production Pipeline
The Production pipeline is the live, customer-facing Snowplow data pipeline. It processes real end-user behavioral data at scale, running the full component stack: Collector → Enrich → Loaders → Data Warehouse.
Key Components
| Collector - receives raw events from trackers over HTTP | |
| Enrich - validates events against schemas, applies enrichments (IP lookup, UA parsing, custom enrichments) | |
| Loaders - writes enriched events to your data warehouse (Snowflake, Databricks, BigQuery, Redshift) | |
| Production Iglu registry - schema repository shared with QA by default |
Use Cases
| Processing real user behavioral data for analytics, ML, and AI applications | |
| Running data models on top of enriched, warehouse-loaded events | |
| Running enrichments (e.g. IP anonymisation, campaign attribution, custom JS enrichments) on live traffic |
⛔ Danger
Schema changes on Production are high-risk. A breaking schema change will cause events to fail validation and land in the bad events stream, resulting in data loss for that event type. Always test schema changes in Mini, Micro, or QA before promoting to Production.
QA Pipeline
The QA pipeline is a full mirror of the Production pipeline, designed as an integrated end-to-end testing environment. It validates that implementation changes work reliably all the way through to the reporting layer - not just at the event collection stage.
What QA Tests
QA pipeline's intent is to confirm that events are:
| Tracked and validated - events pass schema validation (same as Mini/Micro) | |
| Loaded - validates that events are successfully written into the QA warehouse, confirming loader compatibility | |
| Modeled - enables data models (dbt) to run on top of loaded events, validating reporting accuracy |
Use Cases
| Validating a new implementation before go-live - a proof that the full pipeline works end to end | |
| Testing that enrichments produce correct output in the warehouse before enabling them on Production | |
| Verifying data model output (e.g. dbt runs) against test event sets before promoting changes to Prod | |
| Load testing with representative event volumes to confirm infrastructure sizing |
Schema Registry Behaviour
By default, QA pipelines share the schema repository with Production pipelines - not with Snowplow Mini. This means:
| Schemas must be promoted to the Production Iglu registry before QA can validate events against them | |
| It is possible to configure QA to read from the Dev Iglu registry (used by Mini), but this is generally not recommended |
⛔ Danger
Breaking schemas in a QA pipeline is equally destructive as breaking schemas in Production, because QA shares the Production Iglu registry by default. Treat QA schema changes with the same caution as Production changes.
Snowplow Mini
⚠️ Warning
New Snowplow Mini instances are no longer available through Console. For new development environments, use Snowplow Micro instead. Existing Mini deployments continue to function.
Snowplow Mini is a single-instance version of Snowplow that runs the full pipeline (Collector, Enrich, OpenSearch) on a single box. It is primarily a development environment for rapid prototyping of schemas and tracker configurations, but does not write events to a data warehouse or run data models.
Key Components
| Collector - listens on the Mini public IP for incoming events | |
| Stream Enrich - validates events against your custom schemas in the Dev Iglu registry | |
| OpenSearch + Kibana - events (good and bad) are loaded into OpenSearch and can be inspected via Kibana dashboard | |
| Dev Iglu registry - a separate schema registry from Production, allowing draft schema testing without risk |
Use Cases
| Rapid prototyping of new event schemas or context entities in a Dev registry before promoting to Production | |
| Validating that tracker instrumentation fires correctly and events are well-formed before pointing at Production | |
| Testing enrichment configuration changes in isolation before enabling on QA or Production | |
| Inspecting bad events in Kibana to debug schema mismatches in real time |
ℹ️ Note
Snowplow Mini does not load events into a data warehouse. It only loads into OpenSearch. If the goal is to validate warehouse loading or run data models, use the QA pipeline. Even if ElasticSearch/OpenSearch becomes broken due to invalid schemas in Mini, this is isolated and straightforward to fix - it does not affect Production data.
Snowplow Micro
💡 Best practice
Snowplow Micro is the recommended replacement for Snowplow Mini for new testing environments. It can be deployed through Console or run locally, and is purpose-built for automated testing in CI/CD pipelines.
Snowplow Micro is a lightweight version of the Snowplow pipeline. Like a real Snowplow pipeline, Micro receives, validates, and enriches events - but is intentionally minimal, making it ideal for integration into automated test suites and local development workflows. It is not designed for production traffic.
Key Features
| Receives, validates, and enriches events, matching the behaviour of a Production collector and enricher | |
| Exposes a REST API that returns good and bad event counts - ideal for assertions in automated test suites | |
| Can be run locally via Docker or deployed through Console in minutes | |
| Does not write to a data warehouse or run data models - validation only |
Use Cases
| Automated unit and integration testing of tracking implementations in CI/CD pipelines (e.g. GitHub Actions, CircleCI) | |
| Local development - getting familiar with Snowplow event tracking without needing cloud infrastructure | |
| Asserting that a specific number of good events (and zero bad events) are produced by a given user flow or tracker call | |
| Rapid debugging of schema validation failures before escalating to QA |
Quick Comparison
Use this table to quickly identify the right environment for a given task.
2
| Capability | Production | QA Pipeline | Snowplow Mini | Snowplow Micro |
|---|---|---|---|---|
| Event collection | ✅ Yes | ✅ Yes | ✅ Yes | ✅ Yes |
| Schema validation | ✅ Yes | ✅ Yes | ✅ Yes | ✅ Yes |
| Enrichment | ✅ Full | ✅ Full | ✅ Partial | ✅ Partial |
| Warehouse loading | ✅ Yes | ✅ Yes | ❌ No | ❌ No |
| Data modeling (dbt) | ✅ Yes | ✅ Yes | ❌ No | ❌ No |
| Event inspection UI | ❌ No | ❌ No | ✅ Kibana | ✅ REST API |
| Schema registry | Production Iglu | Production Iglu | Dev Iglu | Configurable |
| Automated testing (CI/CD) | ❌ Not recommended | ⚠️ Possible | ⚠️ Possible | ✅ Designed for this |
| Risk of schema breakage | 🔴 Very High | 🔴 High (shared with Prod) | 🟢 Low (isolated) | 🟢 Low (isolated) |
| Available through Console | ✅ Yes | ✅ Yes | ⚠️ No (new deploys) | ✅ Yes |
| Local / self-hosted option | ⚠️ Self-Hosted only | ⚠️ Self-Hosted only | ⚠️ Self-Hosted only | ✅ Yes (Docker) |