Why warehouse-native product analytics on open source changes the build
A regulated digital team that wants product events, funnels and experiment results to live in its own warehouse can build this from open-source parts: an event pipeline feeding ClickHouse or PostgreSQL, funnels and retention modeled in SQL, Superset or Metabase for dashboards, and GrowthBook for experiment analysis. The platform choice is driven less by features than by two questions: who may see which rows and columns, and which edition of each tool includes the access controls you need. In Metabase, for example, SSO, row and column level permissions and usage auditing sit in the Pro and Enterprise plans, not in Open Source or Starter, so the access model has to be settled before the dashboard tool is chosen.
The difference from a single-vendor analytics tool is where the data and the logic sit. A vendor product usually stores events in its own environment and defines funnels in its interface. In a warehouse-native design, the raw events, the SQL models and the retention logic are yours, so a data protection review, a deletion request or a change of dashboard tool does not require re-collecting history. The cost is that you now operate several components, each with its own upgrade path. ClickHouse, for example, needs ClickHouse Keeper for replication and backups that are tested by restoring them on a spare cluster, and Superset needs a metadata database, a caching layer and worker processes for alerts and reports. Confirm which of these your team will run, who patches them, and how each one is backed up before the first event is collected.
DeployOpen plans, implements and hardens these components inside your own cloud accounts, data centers or private networks, including the pipeline, warehouse, BI layer and experiment service, their access integration and their backup and upgrade runbooks. Ask any implementation partner to put in writing which edition of each tool is in scope, how row-level access will be enforced in the warehouse and the dashboard layer, and which restore test proves the backups work. Those answers determine the rest of the build.
Which requirements shape the warehouse design
This table lists the requirements that most often change a warehouse-native analytics build, where each one comes from, and what it means for the design. Read it as a checklist to confirm with your own counsel, security team and platform owners before you choose components.
| Requirement | Source or driver | What it means for the build | What to confirm |
|---|---|---|---|
| Accessibility for public-sector dashboards and embedded content | ADA Title II rule requiring WCAG 2.1 Level AA for state and local government web content; interim final rule dates of April 26, 2027 (50,000 or more people) and April 26, 2028 (smaller entities and special districts) | Dashboards in Superset or Metabase, and any embedded views, must be tested against WCAG 2.1 AA before those dates. Budget for accessibility review of chart types, color use and embedded iframes. | Your applicable compliance date and whether your dashboards count as covered web content, with counsel |
| Superset SECRET_KEY | Superset requires a user-specified SECRET_KEY to start (added in version 2.1.0); PREVIOUS_SECRET_KEY supports rotation | Generate and store the key in a secrets manager before first start. Plan a rotation procedure that uses PREVIOUS_SECRET_KEY so sessions and encrypted values are not broken unexpectedly. | Your key storage, rotation schedule and who approves a rotation |
| Superset metadata database | Superset tests PostgreSQL and MySQL for production; supported versions are PostgreSQL 10 to 17 and MySQL 5.7 and 8.x (configuration documentation) | Use a supported PostgreSQL or MySQL version for the metadata database. Do not use the SQLite default or the Docker Compose PostgreSQL container for production. | Whether your managed database service runs a supported version and offers backups |
| ClickHouse backup and restore testing | ClickHouse backup documentation says replication does not protect against human error or corruption, and warns that an untested backup will probably not restore | Schedule BACKUP to S3-compatible or Azure Blob storage, then run regular restore tests on a spare cluster. Record restore time and data completeness each time. | Backup retention, storage location, restore test frequency and the evidence an assessor will request |
| Metabase row-level and SSO controls | Per Metabase pricing, SSO, row and column level permissions, and multi-tenant segregation are included only in Pro and Enterprise, not Open Source or Starter | If analysts must see only their region or business unit, the Open Source or Starter edition may not meet the access model. Pick the edition before designing permission groups and dashboards. | Current plan features and prices directly with Metabase, since pricing pages change |
| AGPL obligations for Metabase | Metabase open source edition is licensed under the AGPL; commercial editions use the Metabase Commercial Software License | If you modify Metabase and make it available to users over a network, AGPL source-sharing duties may apply. Keep customizations minimal or document how they are shared. Using the unmodified edition internally carries different obligations. | Your licence position with counsel before any code change or embedding plan |
| Regulator-specific retention and residency | Sector and national rules for analytics data, including how long event data and query logs may be kept and where they may be stored | Set ClickHouse TTL rules, dashboard data access logs and backup retention to match the rules that apply to you. Keep the warehouse and backup locations inside the approved region. | Retention periods, data residency and records of processing with your legal and privacy teams |
Which open-source platforms fit each layer and why
A warehouse-native design splits the job into storage, modeling, dashboards and experiment analysis, and each layer has its own licence, operating model and edition limits. The cards below cover the platforms that fit each layer, the decision each one forces, and the checks to run before you commit.
ClickHouse for event storage
ClickHouse is the column store most warehouse-native designs use for high-volume product events. The server is Apache-2.0 licensed, and ClickHouse Inc. sells a managed service separately. Choose between the monthly stable line and the twice-yearly LTS line, and confirm which versions still receive security updates before you pin one. Replicated tables depend on ClickHouse Keeper, so plan at least three Keeper nodes on dedicated hosts.
PostgreSQL as a smaller-volume store
For smaller event volumes, PostgreSQL can hold events, funnel tables and retention models in one database you already operate. It avoids a second storage engine, but funnel and retention queries over large histories will slow down sooner than they would on a column store. Ask your team to test the query set against realistic row counts before committing. Plan for partitioning and retention jobs from the start, since deleting old events in bulk is costly.
Apache Superset for dashboards
Superset is Apache-2.0 licensed with no paid edition, so the feature set in the open-source build is the feature set you get. Alerts, reports, async queries and thumbnails need a Redis caching layer and Celery workers, which adds components to operate. Run the metadata database on PostgreSQL or MySQL, not the SQLite default. Confirm which authentication features, such as OAuth2 group mapping, your chosen version supports in its configuration.
Metabase for self-service analysis
Metabase's open source edition is AGPL licensed, and its commercial editions use a separate licence, so confirm which edition your team needs before rollout. SSO, row and column level permissions and usage auditing sit in the Pro and Enterprise plans, not in Open Source or Starter. The embedded H2 application database is for demos only, so move it to PostgreSQL before production use. Check the version support window for any release you select.
GrowthBook for experiment analysis
GrowthBook handles experiment assignment and statistical analysis, so funnel results in your warehouse can be checked against a controlled test rather than read as correlation. It connects to the warehouse where your events already live, which keeps experiment data in the same place as product analytics. Confirm which warehouse connectors and statistical methods your installed version provides, and who owns metric definitions so that experiments and dashboards agree.
Operations and version discipline
Each layer ships on its own release cadence, so one upgrade plan has to cover all of them. ClickHouse recommends reading the changelog before upgrades because minor backward-incompatible changes can occur. Superset requires a metadata database backup and a check of its breaking-change notes before each upgrade. Restore tests matter as much as backups: ClickHouse's documentation warns that an untested backup will probably not restore when needed. Assign an owner for each layer before go-live.
Integration points and deployment pattern in regulated environments
A warehouse-native analytics stack touches four places an auditor or security team will ask about: who can sign in, where backups go, how the cluster is placed, and where dashboard metadata lives. Each card below names one decision, the supplied platform behavior behind it, and what to confirm in your own environment before the design is fixed.
Identity for the ClickHouse layer
ClickHouse supports LDAP, Kerberos, SSL X.509 certificates, an HTTP authenticator and JWT as external authenticators, so query access can follow your directory rather than local database accounts. Confirm which mechanism your directory team can operate and who owns group-to-role mapping. Service accounts used by the pipeline and by Superset or Metabase should be separate identities with narrow grants, so a dashboard credential cannot write raw events.
Single sign-on for dashboards
Superset supports OAuth2 providers such as Google and Azure, custom OAuth2 servers using the code flow, and LDAP, and it maps LDAP or OAuth groups to roles with AUTH_ROLES_MAPPING. Metabase limits SSO, JWT, OIDC, SAML and SCIM provisioning to its Pro and Enterprise plans. Check the plan tier before choosing Metabase for SSO-bound access, and map each analyst group to the smallest set of datasets it needs.
Backups to local, S3-compatible or Azure storage
ClickHouse BACKUP and RESTORE write full and incremental backups of tables, partitions or databases to local disk, S3-compatible storage or Azure Blob Storage. Replication does not protect against human error or corruption, so the backup target is a separate control. Choose a location outside the cluster's failure domain, set retention in writing, and schedule restores to a spare cluster, because an untested backup will probably not restore when needed.
Replicas and Keeper on dedicated hosts
ReplicatedMergeTree tables are coordinated by ClickHouse Keeper, which replaces ZooKeeper. The replication guide recommends at least three Keeper nodes on dedicated hosts in production, each with about 4 GB of RAM, and a recovered replica syncs missing data from a healthy peer automatically. Keep Keeper nodes off the analytics data hosts so a heavy query or merge cannot starve coordination, and confirm the failure zones your cloud or data center can offer for each node.
Separate metadata databases for dashboards
Superset and Metabase each keep their own application metadata in a database, and both recommend PostgreSQL for production (Superset is tested with PostgreSQL and MySQL). Keep these databases apart from the ClickHouse analytics cluster so a dashboard upgrade or migration does not touch event data. Back up the metadata database before every upgrade, since Superset's upgrade steps and Metabase's migrations both change it.
Version and upgrade control
ClickHouse publishes stable releases roughly monthly and supports LTS lines for a year, while Metabase LTS versions are supported for 14 months. Stable releases are recommended for most production use, and the changelog should be read before any upgrade because minor backward-incompatible changes can occur. Run every upgrade in a pre-production environment with representative data and queries before it reaches the regulated cluster.
How the rollout moves from event schema to tested restores
The sequence turns an agreed event schema into a warehouse-native analytics stack that is tested in staging, handed over with a documented upgrade path, and proven recoverable before go-live. Each phase closes with a named output so the client can sign off before the next one starts.
Agree the event tracking plan and data classification
DeployOpen works with product, data protection and engineering owners to define the events, properties, identifiers and funnels the business needs, then classifies every property by sensitivity and sets which fields may never be captured. The client's data protection lead approves the classification, and the output is a versioned tracking plan with a field-level data map. The step is done when every event has an owner, a purpose and a sensitivity label, and the client has signed the plan in writing.
Build the pipeline and warehouse in staging
The team deploys the event collection pipeline and ClickHouse or PostgreSQL in a staging environment inside the client's infrastructure, with schemas that match the approved tracking plan. ClickHouse clusters are sized with the client's expected event volume and a replica layout that uses ClickHouse Keeper with at least three nodes in production. The output is a staging environment where test events flow end to end, with ingestion errors logged and visible to the operations team.
Model funnels and retention in SQL with reconciliation
Analysts and engineers write the SQL models for funnels, retention and feature adoption, version them in source control and document each metric definition next to its query. Every headline number is reconciled against a source count taken from the application or raw event log, and differences are explained before the model is accepted. The step closes when the reconciliation report shows agreed tolerances for each metric and the client's analytics owner has accepted the definitions.
Configure dashboards and identity
DeployOpen deploys Apache Superset or Metabase against the warehouse, sets up the metadata database on PostgreSQL, and connects single sign-on through the client's identity provider. Role mappings define who sees which datasets, and row-level rules are tested with real user accounts from each group. The output is a dashboard set with access rules documented and tested, and the client has confirmed that group membership in the identity provider controls dashboard access.
Wire GrowthBook experiment analysis
The team connects GrowthBook to the same warehouse so experiment assignments and exposure events are analyzed from the agreed tables rather than from a separate copy of the data. Assignment logging is checked against a test experiment, and the statistics settings are reviewed with the client's experimentation owner. The output is one test experiment analyzed end to end, with results that match a manual SQL check.
Prove backups restore on spare clusters
Backups are taken with ClickHouse BACKUP to the storage target the client approves, covering full and incremental runs. The team restores them to a spare cluster and to a restored metadata database, then compares row counts and key metrics against production. Replication is not treated as a backup, because it does not protect against human error or corruption. The output is a restore test report with timings and discrepancies recorded, and a schedule for repeating the test.
Go live with an upgrade runbook
At go-live, DeployOpen hands over a runbook that covers each upgrade path: back up the Superset metadata database, run the database upgrade and init commands, and review UPDATING.md for breaking changes; back up the Metabase application database, run the migrations in staging first, and plan the single-node step for major upgrades. The runbook also requires a review of the ClickHouse changelog before each change, since minor releases can contain backward-incompatible changes. The output is a signed runbook, a rehearsed staging upgrade, and a named owner for each product.
Evidence assessors ask for and the component that produces it
This table maps the evidence an assessor typically requests for a warehouse-native analytics stack to the component that produces it. Read each row as a question an assessor will ask, the artifact that answers it, and the system that generates the artifact. DeployOpen prepares this evidence, but independent auditors issue any assessment outcome.
| Evidence requested | Component that produces it | Where it usually falls short |
|---|---|---|
| Access review of who can open dashboards and query tables | SSO group mapping in Superset (AUTH_ROLES_MAPPING) or Metabase Pro/Enterprise group sync, plus ClickHouse access control user and role grants | Metabase SSO group sync needs Pro or Enterprise; open source and Starter cannot produce this export |
| Backup and restore test records | ClickHouse BACKUP and RESTORE jobs, with logs from restores run on a spare cluster | A backup that has never been test-restored is unproven; no restore log means no evidence |
| Metadata database backup records for Superset and Metabase | PostgreSQL backup tooling and Metabase application database backups taken before each upgrade | Backups exist but no one has confirmed they restore; the H2 file is not a production store |
| Upgrade and change log | Pre-production test records, superset db upgrade and init output, Metabase migration logs, ClickHouse changelog review before each upgrade | Upgrades applied without staging evidence or without a recorded review of breaking changes |
| Data flow diagram from event collection to dashboards | Event pipeline configuration, ClickHouse ReplicatedMergeTree and Keeper topology, Superset and Metabase database connections | Diagrams drawn once and not updated after new sources or tables are added |
| Retention configuration for raw events and aggregates | ClickHouse TTL settings on tables and partitions, plus documented retention decisions per dataset | Retention set on raw tables but not on derived SQL models or dashboard exports |
| Dashboard and saved query permission export | Superset and Metabase role or permission exports, reviewed against the access review | Exports are not scheduled, so changes between reviews go unrecorded |
| Experiment analysis access and results records | GrowthBook connected to the same warehouse, with queries and result snapshots retained | Experiment results used in decisions without a record of the query and data version |
What do teams ask before building a warehouse-native analytics stack?
What does a warehouse-native analytics stack cost to run?
The software can be free to license, but the total cost is paid in infrastructure, implementation labor and ongoing operation. ClickHouse server is open source under the Apache License 2.0, and Apache Superset has no paid edition. Metabase publishes an Open Source plan at no charge, Starter at $100 per month ($90 per month billed yearly, first 5 users included) and Pro at $575 per month ($517.50 per month billed yearly, first 10 users included), with Enterprise priced by quote starting at $20,000 per year (Metabase pricing page). Recurring costs include servers, storage, backups and staff time for upgrades. Ask any quote to separate one-time build work from monthly support and to state what the infrastructure assumes about event volume and retention.
Which Metabase edition do we actually need for SSO and row-level security?
Choose Pro or Enterprise if you need SSO beyond Google sign-in, row and column level permissions, multi-tenant data segregation or usage auditing. According to the Metabase pricing page, these features are included only in the Pro and Enterprise plans, not in Open Source or Starter. SAML, OIDC, JWT, advanced LDAP group sync and SCIM provisioning also require Pro or Enterprise (Metabase people and groups documentation). If your access model needs only shared dashboards and Google or basic LDAP sign-in, Open Source or Starter may be enough. Map your access requirements to these features before you choose, and confirm current edition terms with Metabase because pricing pages change.
How long does a warehouse-native analytics build take?
Timing depends on the number of event sources, the number of funnels and retention models, how much the team needs to tune ClickHouse, and how many dashboards and experiment readouts must be connected. No duration is fixed here, so ask for a written timeline tied to a written scope. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. The client typically provides infrastructure access, a named data owner for event definitions, identity provider details, and staff for sign-off on dashboards and metrics. Ask whether the timeline includes a pre-production environment loaded with representative data.
Can our internal data team run this stack without outside help?
A team with data engineering and platform skills can run it, but the work is continuous rather than one-time. ClickHouse recommends a pre-production environment, reading the changelog before upgrading because minor backward-incompatible changes can occur, and running stable releases for most production use. Superset requires a configured metadata database (PostgreSQL or MySQL, not the SQLite default), a SECRET_KEY, and a caching and worker layer for alerts and reports. Ask yourself who owns Keeper quorum, backup restore tests and upgrade windows. If those owners are not named, plan for a retainer for support, upgrades and testing.
How are ClickHouse upgrades and version support handled?
Stable releases ship roughly monthly, the three latest stable releases receive diagnostics and bug fix backports, and LTS releases ship twice a year with one year of support (ClickHouse production FAQ). The ClickHouse security policy lists versions 26.9, 26.8, 26.7 and 26.3 as supported with security updates. Plan upgrades in a staging cluster with representative data, check the changelog for backward-incompatible changes, and run upgrades on a schedule you can keep. Confirm with your implementation partner who performs each upgrade, how rollback works, and whether the retainer covers monthly stable updates.
How do we back up ClickHouse and Superset without losing data?
Replication does not protect against human error or data corruption, so you need separate backups. ClickHouse BACKUP and RESTORE support full and incremental backups of tables, partitions or databases to local disk, S3-compatible storage or Azure Blob Storage (ClickHouse backup documentation). Back up the Superset metadata database before every upgrade and run superset db upgrade and superset init after updating, testing in staging first. Metabase recommends backing up its application database before upgrades. The ClickHouse documentation warns that a backup never test-restored will probably not restore properly, so schedule restore tests on a spare cluster.
Which dashboard tool fits best, Superset or Metabase?
Choose Superset if your team prefers SQL-first exploration, Apache-licensed code with no paid edition, and can operate a Flask application with Redis and Celery. Choose Metabase if business users need a point-and-click query builder and you accept its AGPL open source edition or a paid plan for enterprise identity features. Superset's Helm chart is marked deprecated in current development documentation, which points new Kubernetes deployments to the Apache Superset Kubernetes Operator. Test both against your warehouse and access model with a short proof of concept before committing.
How a team should decide between Superset and Metabase
The choice between Apache Superset and Metabase comes down to who will run the tool and which access controls you need on day one. Superset is a multi-component system: the Flask and React application, a metadata database, an optional caching layer and optional Celery worker and beat processes. Its documentation says alerts and reports, async queries and dashboard thumbnails need the caching layer and workers, and most installations use Redis and Celery for them. Metabase ships as a single JAR with an embedded H2 application database for demos, and its documentation recommends PostgreSQL for production. For a small team, that difference in moving parts is often the deciding factor, but a team that already runs Kubernetes may prefer Superset's path, which the Apache Superset Kubernetes Operator now documents for new deployments because the Helm chart is marked deprecated.
Access controls are where the editions differ most. Superset is Apache-2.0 with no paid edition, and it supports OAuth2 providers, LDAP and group-to-role mapping through AUTH_ROLES_MAPPING. Metabase's open source and Starter plans support Google sign-in and LDAP, while SSO, row and column level permissions, and usage analytics and auditing are included only in the Pro and Enterprise plans, according to its pricing page. If your warehouse analysts must see only their own region or tenant, confirm that row-level security is available in the edition you intend to license and that the license terms fit your use. Ask the vendor for the current pricing and feature matrix in writing, because these plan boundaries change.
Before choosing, the team that will maintain the tool should check the upgrade path and the support windows. Superset's upgrade guidance asks you to back up the metadata database, run superset db upgrade and superset init, test in staging, and read UPDATING.md for breaking changes. Metabase runs application database migrations automatically, recommends backing up the application database first, and documents the migration lock that makes reducing a cluster to one node necessary for major upgrades. Metabase publishes support windows, with LTS releases supported for 14 months, so confirm which version line your organization will track. Also confirm your secret management for Superset's required SECRET_KEY, and whether your identity provider's groups map cleanly to roles in either tool before you commit.
How DeployOpen works on this
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For warehouse-native product analytics, that means a written scope covering event collection, warehouse modeling, dashboards and experiment analysis, delivered in your environment with your data staying where your warehouse lives.
How we scope
- Inventory the product events, identifiers and consent states your teams need before choosing ClickHouse or PostgreSQL as the target.
- Agree in writing which SQL funnel and retention models, dashboards and GrowthBook experiments are in and out of scope.
- Confirm the hosting boundary, backup targets and access groups so the scope matches your own network and data location rules.
How we build
- Deploy the event pipeline, warehouse, Superset or Metabase, and GrowthBook inside your infrastructure, with versions pinned to supported releases.
- Configure ClickHouse replication with Keeper, backups and restore tests, and the external authentication your directories already use.
- Test event loss, schema changes and dashboard permissions in a staging environment before any production cutover.
How we hand over
- Document architecture, data flows, SQL model definitions, dashboard ownership and the upgrade runbook for your operations team.
- Run a restore test with your team present and record the result as evidence for your own backup and continuity reviews.
- Hand over credentials, admin roles and access reviews so your staff can operate the stack without DeployOpen in the loop.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial fixed-scope build.
- Plan upgrades against the vendor support windows for ClickHouse, Superset and Metabase, testing each step in staging first.
- Prepare control and configuration evidence for your compliance assessments, while independent auditors issue any formal opinion.
