How data warehouse architecture works in 2026: storage and compute separated over object storage, open table formats as the warehouse interface, multi-engine query, streaming ingestion, and why the classic three-tier model no longer fits.
Most explainers on "data warehouse architecture" still draw the same picture they drew a decade ago: sources feed a staging area, ETL jobs clean and load the data, a warehouse stores it, and BI tools read from the warehouse. The diagram is obsolete. Each of its boxes has been pulled apart and replaced by something else.
In 2026 a data warehouse is rarely a single storage engine. It is a query and governance interface on top of open table formats, which sit on commodity object storage. Storage and compute are separate services bought separately. Multiple engines read and write the same physical tables. Streaming data lands in those tables within seconds to a minute, depending on commit interval, instead of waiting for a nightly batch. This post walks through that architecture layer by layer, explains why the three-tier model broke, and ends with how to migrate a Redshift- or Snowflake-only stack toward it without a big-bang cutover.
For the platform-wide view of how all of this fits together, see our companion piece on the modern data platform in 2026. If you want the category-level distinctions first, start with EDW vs data lake vs lakehouse.
Why the Classic Three-Tier Model Broke
The classical design was source -> staging -> warehouse -> BI, with the warehouse owning its own tightly coupled storage and compute. Teradata, early Redshift, and on-prem Oracle all worked this way: you sized a cluster, your data lived inside it, and adding query capacity meant adding storage you did not need (or the reverse). That coupling is the first thing to fall.
Three forces broke it. Cloud object storage made keeping a second full copy of data inside the warehouse hard to justify: it is much cheaper than warehouse-attached disk, and you no longer buy storage in cluster-node increments alongside compute you do not need. Open table formats gave object storage the ACID transactions, schema evolution, and snapshot isolation that previously only a warehouse could offer. And streaming and machine learning workloads meant the same datasets had to be readable by SQL engines, Spark jobs, and Python notebooks at once, which a closed single-engine warehouse cannot do.
The tiers did not disappear. They moved. Staging became a streaming ingestion layer. The warehouse storage tier became object storage plus a table format. The compute tier became a fleet of interchangeable engines. The BI tier got a semantic layer in front of it.
The Foundation: Object Storage and the Storage-Compute Split
Separation of storage and compute is the decision everything else depends on. Data sits in cloud object storage (Amazon S3, Google Cloud Storage, Azure Data Lake Storage), and compute clusters are stateless services that read from and write to that storage over the network. You scale them independently. A reporting team can spin up a small warehouse, a backfill job can spin up a huge one, and both hit the same bytes without copying anything.
Snowflake popularized this pattern commercially with its three-layer model of a storage layer, independent virtual warehouses for compute, and a cloud services layer for metadata and optimization. The open lakehouse generalizes the same idea but makes the storage layer non-proprietary: instead of Snowflake's internal micro-partition format, the data sits in open Parquet files that any engine can read. We covered the commercial version of this split in our Databricks vs Snowflake 2026 comparison.
The trade-off is latency. Object storage is high-throughput but high-latency compared to local NVMe, so engines lean on caching, columnar formats, and predicate pushdown to compensate. For analytical scans this is a good deal. For single-row point lookups it is not, which is one reason transactional (OLTP) systems stay separate from analytical (OLAP) ones; see OLTP vs OLAP in 2026.
The Contract Layer: Open Table Formats as the Warehouse Interface
A pile of Parquet files in a bucket is a data lake, and historically that meant no transactions, no safe concurrent writes, and a query planner that had to list every file to know what existed. Iceberg, Delta and Hudi fix this with a metadata layer over those files: a manifest of which files are in the table at each snapshot, plus enough bookkeeping for ACID commits, schema and partition evolution, and time travel, so independent engines can read and write the same table safely.
This layer now plays the role the warehouse storage engine used to play. Instead of "the warehouse owns the data," the table format owns the data, and the warehouse is one of several clients. Iceberg has become the de facto interoperability standard, and the Apache Iceberg table format post explains why its design won over the Hive table layout it replaced.
The catalog completes the contract. The Iceberg REST Catalog specification standardizes how engines discover tables and commit changes, and Apache Polaris implements it as a vendor-neutral catalog service. Polaris was co-created by Snowflake and Dremio, entered the ASF incubator in August 2024, and graduated to a Top-Level Project in February 2026. A catalog that speaks the Iceberg REST API is what lets Trino, Spark, and Snowflake agree on what a table is.
The Compute Layer: Many Engines, One Set of Tables
Once data lives in open tables behind a shared catalog, compute stops being a single product and becomes a choice per workload. The same Iceberg tables can be queried by Trino for interactive SQL, processed by Spark for heavy batch jobs, written by Flink for streaming, and scanned by ClickHouse for low-latency analytics.
The commercial platforms have conceded this. Apache Iceberg tables for Snowflake reached general availability in June 2024 with Snowflake version 8.20; external engines reach Snowflake-managed tables through its Iceberg REST endpoint (Open Catalog, Snowflake's managed Polaris). Databricks followed: it previewed managed Iceberg tables behind Unity Catalog's Iceberg REST API at Data + AI Summit in June 2025 and took them GA in May 2026, along with Iceberg v3 and foreign Iceberg catalogs, so Spark, Flink, Trino, DuckDB and Snowflake clients can read and write the same tables. When the two largest analytics vendors both ship read/write Iceberg interop, single-engine lock-in is no longer the default. Our practical guide to ClickHouse and Iceberg integration shows what this looks like for a fast OLAP engine reading the lakehouse directly.
Picking engines per workload has a cost: governance and observability now span multiple systems instead of one. Permissions, lineage, and cost attribution have to be enforced at the catalog and storage layer rather than inside a single product, which is harder and a frequent source of production gaps.
Streaming as a First-Class Input
In the old model, freshness was a batch-window problem: data was as current as the last nightly or hourly load. The 2026 architecture treats streaming as a primary ingestion path. Events flow from Kafka through a stream processor (commonly Apache Flink) and land directly in Iceberg tables, where the same tables serve both the streaming writes and downstream analytical reads.
This collapses the old staging tier. Change Data Capture (CDC) streams from operational databases replay inserts, updates, and deletes into lakehouse tables continuously, so the warehouse reflects source-system state within seconds to a minute rather than hours. Iceberg's snapshot model and row-level deletes make this safe: a streaming writer can commit small files frequently while readers see consistent snapshots, and a background compaction job merges the small files later. See our guide on Flink and Iceberg for modern data lakes.
The pitfall is file fragmentation. High-frequency commits produce many small files and large delete manifests, which degrade read performance until maintenance runs. Compaction, snapshot expiration, and manifest rewriting are operational requirements in a streaming lakehouse, as we cover in Iceberg table maintenance best practices.
Choosing an Architecture: Lakehouse vs Cloud DW vs Real-Time OLAP
The decision turns on workload mix, engine diversity, and how much platform engineering you can staff. A single-engine cloud data warehouse is still the simplest thing that works for a team doing pure SQL analytics with no streaming or ML.
| Dimension | Open Lakehouse | Single-Engine Cloud DW | Real-Time OLAP |
|---|---|---|---|
| Storage | Object storage + open table format | Vendor-managed (often proprietary) | Engine-managed |
| Compute | Multiple engines, same tables | One engine | One engine |
| Best for | Mixed SQL + Spark + streaming + ML | SQL-first analytics, BI | Low-latency serving on fresh data |
| Lock-in risk | Low (open format + REST catalog) | Higher (data inside the platform) | Higher |
| Operational burden | High (compaction, multi-engine governance) | Low | Medium |
| Freshness | Seconds to a minute (with streaming) | Minutes to hours (batch) | Sub-second |
| Examples | Iceberg + Trino/Spark/Flink | Snowflake, BigQuery, Redshift | ClickHouse, Apache Pinot |
Migrating Without a Big-Bang Cutover
A migration from a legacy Redshift- or Snowflake-only stack is incremental. The sequence we use:
- Pick the catalog first. Stand up a REST-spec catalog (Polaris, Lakekeeper, or Glue's REST endpoint) before landing a single table, because every later step registers tables and grants there.
- Land new and high-volume datasets in Iceberg. Event streams and CDC feeds that would otherwise cost the most to hold inside the warehouse go to Iceberg from day one. Nothing existing moves yet.
- Point the warehouse at the lake. Snowflake, BigQuery, and Redshift all read Iceberg, so existing dashboards can join warehouse tables with lake tables with no ETL in between. This is the dual-read period: the same table is queried from both sides, and you compare row counts and aggregates until they match.
- Move tables one at a time, coldest first. Historical partitions and rarely-queried fact tables go first; they are cheap to validate and nobody notices a latency change. Certified finance tables go last, if at all.
- Cut over when three things hold for a given table: the lake copy has matched the warehouse copy for a full reporting cycle, every consumer has been repointed, and the maintenance jobs (compaction, snapshot expiry) have run unattended for as long. Then drop the warehouse copy.
The warehouse keeps serving what it already serves while the open layer grows underneath it, and the tables that never justify the move stay put. For the broader landscape, including the 2022 prior-generation reference, see our original architectures of a modern data platform post and the updated ClickHouse vs Snowflake comparison.
Key Takeaways
- The three-tier model broke because object storage, open table formats, and streaming/ML workloads each dissolved one of its coupled walls. The tiers moved rather than vanished.
- The table plus its catalog owns the data now; the warehouse is one client among several. Snowflake (Iceberg GA June 2024) and Databricks (managed Iceberg GA May 2026) both ship read/write interop.
- The lakehouse is not free. Multi-engine governance and mandatory table maintenance are real costs; a single-engine cloud DW remains the simpler choice for SQL-only analytics, and migration should proceed table by table with a dual-read period, not as a rewrite.
If you are weighing a lakehouse move or untangling a multi-engine stack, BigData Boutique does this work with data teams. Reach out.
