--- title: "Warehouse-native Amplitude: how it works" canonical_url: https://ampl.webclat.com/guides/warehouse-native-amplitude-how-it-works description: "What running Amplitude warehouse-native actually means - analyzing event data that stays in your own Snowflake, BigQuery, or Databricks instance - and how to plan a build on top of it." source: Webclat | Amplitude Solutions (official Amplitude partner, independent consultancy) --- # Warehouse-native Amplitude: how it works **In short:** Warehouse-native Amplitude means Amplitude's analysis layer (cohorts, funnels, retention, dashboards) queries event data that stays in your own data warehouse - Snowflake, BigQuery, Databricks - instead of requiring that data to be duplicated into Amplitude's own event store first. It's a fit for teams whose event data already lives in a governed warehouse and want Amplitude's analytical UI on top of it without a second, parallel copy of the truth. ## What it is In Amplitude's default architecture, events are sent to Amplitude's own ingestion pipeline and stored there, and all analysis runs against that stored copy. Warehouse-native inverts the storage side of that: Amplitude builds its charts and cohorts by querying tables that live and stay in the customer's own warehouse, rather than importing the underlying event rows into Amplitude's infrastructure first. This matters most for organizations with an existing warehouse-first data stack (dbt models, a governed event schema already maintained by a data engineering team) who want product-analytics tooling without introducing a second data store that can drift out of sync with the warehouse's own definitions. ## When you need it - Your organization already has a mature, governed event pipeline landing in a warehouse (via dbt, Fivetran, or a custom pipeline) and doesn't want product analysts working from a second, potentially-inconsistent copy of that data inside a separate analytics tool. - Data residency, security, or compliance requirements make it preferable - or mandatory - for raw event data to never leave infrastructure you control, which a warehouse-native architecture supports in a way a standard SaaS-ingestion model does not. - You want product managers and growth teams using Amplitude's cohort, funnel, and retention UI, but want the underlying event definitions to be owned and versioned by the data engineering team's existing warehouse models, not duplicated and redefined inside Amplitude separately. ## Implementation, done properly 1. Start from the warehouse schema, not from Amplitude's UI - the events and properties a warehouse-native Amplitude instance can analyze are only as clean as the tables it points at, so any existing schema debt (inconsistent event naming, untyped properties) needs the same tracking-plan discipline a standard Amplitude rollout needs, just applied at the dbt/warehouse layer instead of at the SDK layer. 2. Model the tables Amplitude will read as their own defined layer (commonly a dedicated dbt model or schema), rather than pointing Amplitude directly at raw, unmodeled event tables - a clean, purpose-built layer is easier to reason about when something in Amplitude's UI doesn't match expectations, and it isolates Amplitude's read pattern from unrelated changes elsewhere in the warehouse. 3. Plan for query cost and latency deliberately: because analysis runs as live (or near-live, depending on refresh configuration) queries against your own warehouse rather than a pre-indexed store Amplitude manages, both the warehouse compute bill and the responsiveness of Amplitude's charts depend on how the underlying tables are structured and partitioned - this is a real engineering tradeoff, not just a configuration checkbox. 4. Decide identity resolution logic at the warehouse-model layer, since warehouse-native Amplitude reads whatever user/device identity mapping the underlying tables already encode - if that mapping is inconsistent in the warehouse, it will be inconsistent in every Amplitude chart built on top of it, and there's no separate Amplitude-side identity-merge step to compensate. 5. Pilot with a narrow, well-understood set of tables and a small group of internal users before rolling warehouse-native access out broadly - the failure modes here (a slow-loading dashboard, a cohort that silently excludes a data slice due to a warehouse-side filter) are easier to catch and fix in a small pilot than after wide adoption. ## How to verify it worked 1. Build one simple chart (a basic event count or a small funnel) on a table you can also query directly in the warehouse's SQL editor, and confirm the two numbers match exactly - this is the fastest sanity check that the warehouse-native connection is reading the table correctly. 2. Check query latency and cost for a representative dashboard under real usage, not just a single test load - warehouse-native performance depends on your warehouse's own query engine and table structure, so it needs to be validated against your actual data volume, not assumed from documentation alone. 3. Confirm a known user's identity resolves consistently: pick a real user with activity across more than one tracked surface, and verify their combined event history appears as one coherent profile inside Amplitude's warehouse-native view, matching what a direct warehouse query for that same user would show. 4. Re-run the same set of verification checks after any change to the underlying dbt models or warehouse schema - because warehouse-native Amplitude has no independent copy of the data to fall back on, a schema change upstream can silently break a chart in a way a standard Amplitude setup, with its own stored event copy, would not. ## FAQ ### Does warehouse-native mean giving up Amplitude's other features, like session replay or AI agents? Features that depend on Amplitude's own client-side capture or its native event store may have different requirements or availability under a warehouse-native architecture than under standard ingestion - confirm which specific Amplitude features are supported warehouse-native against current documentation before assuming full feature parity. ### Can we run a hybrid setup - some data warehouse-native, some ingested normally? Amplitude's architecture is built to support analyzing warehouse-resident data as well as natively-ingested event data, so a hybrid approach is generally the more common real-world pattern than an all-or-nothing switch - but the exact mechanics of blending the two inside one project should be checked against current documentation and planned deliberately rather than assumed to work seamlessly by default. Related: [Amplitude warehouse metrics and the Data Warehouse MCP server](https://ampl.webclat.com/guides/amplitude-warehouse-metrics-and-the-data-warehouse-mcp-server), [Amplitude implementation sprint](https://ampl.webclat.com/services/amplitude-implementation), [Use case: product analytics without a data engineer](https://ampl.webclat.com/use-cases/product-analytics-without-a-data-engineer)