# Warehouse-native, warehouse-connected and export routes "Warehouse" on a vendor page can mean four different architectures. Decide which one the recommendation needs before comparing tools, because cost, freshness, permissions and failure modes differ. ## Contents - Four architectures - When warehouse-native fits - When it does not - How to verify where the query runs - Model checks - Candidates - Cost lines - Freshness - Permissions and data boundary ## Four architectures - Native: the report's query runs in your warehouse. Examples: Statsig Warehouse Native, which Statsig says runs analysis directly in the data warehouse; Mitzu; GrowthBook connected to your own warehouse. - Import: warehouse tables are copied into the vendor's engine and queried there. Mixpanel warehouse connectors bill inserted rows as events, and Mirror updates and deletes as events too. PostHog connector sources (Snowflake, BigQuery, Databricks and others) are synced into PostHog infrastructure and queried there, not inside your warehouse. - Vendor compute over your storage: the data stays in your object storage and the vendor's engine reads it at query time. PostHog custom sources (S3, GCS and similar) work this way: PostHog does not copy the files into its storage, but the SQL runs on PostHog compute, not in your warehouse. Freshness is whatever your files are. Source: posthog.com/docs/data-warehouse/under-the-hood. - Export: product events are sent from the hosted tool to your warehouse for joins with billing and CRM. Mixpanel Data Pipelines (Growth or Enterprise add-on), PostHog batch exports (S3, Snowflake, BigQuery, Postgres, Redshift, Databricks, Azure Blob Storage; 5-minute to weekly schedules), Heap Connect (Pro add-on, included in Premier), GA4 BigQuery export (standard daily export limited to 1 million events a day). An import can still be the right answer. It gives the team a hosted interface. Record the extra copy and test how a corrected property or a deletion reaches the report. ## When warehouse-native fits All must hold: - Product events, identities and the commercial state the question needs (trial, plan, revenue) already sit in maintained warehouse models. - A named person owns those models, their freshness and their failed jobs. - The decision tolerates the slowest source's delay. Overnight billing loads make a "live" funnel daily. - The interface supports the recurring question for the intended operator, not only for the data team. It is strongest when product outcomes need commercial context already modelled in the warehouse, and when copying data into another vendor is itself a constraint. ## When it does not - No warehouse models yet. A hosted tool fed by SDK events usually reaches a first useful report sooner; building the data operation first delays every decision. - Nobody owns the models. A direct connection cannot recover an unrecorded event or settle an ambiguous definition. - The main need is a session-level, real-time investigation workflow with replay. ## How to verify where the query runs - Run one representative report, then find it in the warehouse query history under the tool's service identity. - Ask the vendor for a diagram of raw data, execution, intermediate tables, cached results and application metadata, then compare it with the connection settings. - Check whether samples, aggregates or caches are stored by the service. "Data stays in the warehouse" rarely covers all of them. ## Model checks Run these on the models a native tool will query, before the pilot: - Denominator: units with zero qualifying events stay in the cohort. A model built only from successful events gives a flattering rate that excludes every failure. - Grain: joins keep the analysis unit's grain. Joining invoices to events on `workspace_id` multiplies rows; aggregate one side to the unit first, then join. - Time: commercial state (trial, plan) is evaluated at the time of the event, not today's value. - Reconcile one known cohort to application records before any chart is trusted. ## Candidates Checked on 2026-10-17; prices in [billing-meters.md](billing-meters.md). - Mitzu: product exploration on warehouse tables, unlimited events, priced by editor seats. Analyst has no viewer seats; Team has unlimited viewers. - GrowthBook: experimentation and product analytics sharing warehouse metric definitions, priced per seat, with bring-your-own-warehouse on the cloud plans. Plan gates: explorers run on all plans, but saved custom SQL reports and private dashboards need Pro, and sharing dashboards across the organisation needs Enterprise. Starter's three free users cannot run a shared reporting workflow. Source: docs.growthbook.io/app/product-analytics. - Statsig Warehouse Native: experimentation from your tables, Enterprise tier. Amplitude announced on 5 May 2026 that it will take on Statsig's brand and customers; confirm the contracting entity and support in writing. - Datadog Experiments (formerly Eppo; geteppo.com now presents it as Datadog Experiments): experimentation on a warehouse-native, zero-copy architecture, for teams that want shared metric governance. No public free or startup offer verified; get deployment and pricing terms. Ask what results, metadata and caches leave the warehouse, since a zero-copy label does not answer that. - Optimizely Analytics (warehouse-native experimentation analytics): connects Snowflake, BigQuery, Databricks and Redshift, needs a schema it can write to for cached computations, and materialises intermediate results. Fits a team already running Optimizely experiments whose outcomes live in the warehouse. Source: docs.optimizely.com, "Get started with Warehouse-Native Experimentation Analytics". - Amplitude: has published warehouse-native capabilities in the past. Ask in writing which warehouse-native product, warehouses, charts and terms are offered today, separately from its import connectors. ## Cost lines - Software: seats (Mitzu, GrowthBook), Enterprise contract (Statsig Warehouse Native), or events when the route is an import. GrowthBook cloud also meters its managed warehouse and CDN; see [billing-meters.md](billing-meters.md). - Incremental warehouse compute and storage: queries, refreshes, concurrency and intermediate tables. Attribute only the workload the new tool adds. - Model maintenance hours, measured during the pilot. In practice this line decides most comparisons: a native setup on immature models can cost more per month than a hosted tool, and the same setup on mature reusable models can cost less. - Fictional planning example at a USD 90 hourly rate, per month: ```text native, models need maintenance: 600 platform + 180 compute + 16 h x 90 = USD 2,220 replicated, lighter operation: 850 platform + 90 sync + 9 h x 90 = USD 1,750 native, mature reusable models: 600 platform + 180 compute + 5 h x 90 = USD 1,230 ``` The same native setup is USD 470 dearer or USD 520 cheaper than the replicated route depending only on model maintenance. Measure the hours in the pilot rather than assuming them. - Cost controls: for BigQuery on-demand, Google recommends dry runs and the maximum bytes billed setting; confirm the tool's service identity is subject to them, not only an analyst's notebook. On Snowflake, a virtual warehouse bills while running and idle, with a minimum charge each time it starts or resumes, so a tool that wakes it for every chart pays that minimum repeatedly; check auto-suspend and the refresh schedule. Source: docs.snowflake.com/en/user-guide/cost-understanding-compute. Tag the tool's jobs so a cost alert names the report. ## Freshness Freshness is set by the slowest step: source arrival, model build, query and cache. Example: event at 09:00, in the warehouse at 09:12, in the model at 09:30, in a cached result at 09:45, read at 09:50. Write the acceptable delay for each decision in the memo. ## Permissions and data boundary - A single broad service account does not enforce each viewer's own warehouse permissions. Test one report with two users who should see different data, including drilldowns, exports and shared links. - Small aggregates can still disclose individual behaviour. Set dimension and drilldown limits. - Revocation, deletion of a customer record and expiry of a cached result are separate actions. Test each that matters.