For most of the last decade, the warehouse-versus-lakehouse debate was framed as a choice between two camps. Warehouses offered polished SQL, high concurrency and minimal operations, but stored data in proprietary formats inside one vendor’s engine. Lakehouses offered open formats on cheap object storage and freedom to use many engines, but demanded more engineering to reach warehouse-grade performance and governance. That framing is now out of date. In 2026 the major warehouses read and write Apache Iceberg tables in customer-owned storage, lakehouse platforms serve dashboards to thousands of users, and cloud providers sell managed Iceberg storage as a primitive.
The convergence does not make the decision irrelevant. It changes the question. Instead of “warehouse or lakehouse,” the useful questions are: where does the authoritative copy of the data live, who owns the catalog that governs it, which engines need to read and write it, and how much platform engineering are you prepared to own? This guide explains what has changed, lays out the four architecture patterns that actually appear in 2026 programs, and gives decision criteria, a worked example and a migration playbook.
What Has Changed Since the Original Debate
Three developments over the past two years have blurred the lines.
Warehouses went open
Snowflake, Google BigQuery and Amazon Redshift all support Iceberg tables. Snowflake’s Horizon Catalog moved to full bidirectional interoperability in 2026: its engineering blog describes external engines such as Apache Spark and Trino writing to Snowflake-managed Iceberg tables through open catalog APIs, including Apache Polaris, while Snowflake can write to tables in external catalogs. External-engine writes became generally available in May 2026 according to Snowflake’s release notes. Google’s BigQuery now offers Apache Iceberg managed tables that store Parquet data and Iceberg metadata in a Cloud Storage bucket the customer owns, with DML, high-throughput streaming through the Storage Write API, automatic file optimization and fine-grained security. Google’s documentation notes that storage is billed through Cloud Storage rather than as BigQuery storage.
Object storage learned about tables
Amazon S3 Tables provides Iceberg tables as a managed storage type with automatic maintenance, an Iceberg REST catalog endpoint and, since December 2025, automatic replication of tables across regions and accounts, queryable from Athena, Redshift, Spark, DuckDB and other Iceberg-compatible engines. Table maintenance, once one of the main operational burdens of a do-it-yourself lakehouse, is increasingly a managed service.
The catalog became the control point
When several engines can read and write the same tables, the catalog decides who can see what and which version of a table is current. Unity Catalog, Apache Polaris, Snowflake Horizon, AWS Glue and BigLake metastore now compete for that role. We compare them in choosing a lakehouse catalog, and cover format evolution in Apache Iceberg v3 and the open table format standard.
In 2026 the real decision is not warehouse versus lakehouse. It is who owns the storage, who owns the catalog and how many engines must share one governed copy of the data.
The Four Architecture Patterns You Will Actually Choose Between
Pattern 1: Warehouse-native
Data lives in the warehouse’s own managed storage and format. You get the simplest operations, mature concurrency, built-in governance and the best-tuned performance for that engine. The trade-off is that other engines reach the data only through connectors, exports or sharing features, and moving away later means a full data migration. This remains a strong choice for organizations whose workloads are overwhelmingly SQL and BI, with a small data team and no need for multi-engine access.
Pattern 2: Warehouse with open tables
The warehouse remains the primary engine and governance plane, but key tables are stored as Iceberg in your own object storage, managed by the warehouse’s catalog. Spark jobs, data science notebooks or another engine can read, and increasingly write, the same tables. This pattern keeps most of the warehouse experience while lowering lock-in and avoiding duplicate copies for machine learning. Watch the details: features such as clustering, streaming ingestion or certain security controls may behave differently on Iceberg tables than on native ones, and Google’s documentation explicitly warns that files changed outside BigQuery can cause query failures or data loss for its managed tables.
Pattern 3: Lakehouse platform
A single platform, such as Databricks or Microsoft Fabric, provides storage in open formats, a catalog, Spark and SQL engines, BI serving and machine learning tooling. You get open formats with an integrated experience, strong support for data engineering and data science on the same data, and growing SQL warehouse capabilities. The trade-off is that the platform’s catalog and compute become your center of gravity, even if the files themselves are open.
Pattern 4: Composable open lakehouse
Storage, catalog and engines are chosen independently: for example, managed Iceberg storage, an open REST catalog, Spark or Flink for processing, Trino for interactive SQL and DuckDB for lightweight analytics. This offers maximum flexibility and the lowest lock-in, and it can be very cost-efficient at scale. It also demands the most platform engineering, because you assemble security, observability, performance tuning and support across components yourself.
Decision Criteria That Actually Discriminate
Most feature comparisons are no longer useful, because every serious platform supports SQL, ACID tables, time travel and role-based access. These criteria still separate the patterns:
- Engine diversity. If one SQL engine serves almost everything, Pattern 1 or 2 is enough. If data engineering, streaming, data science and AI workloads each want different engines on the same data, Patterns 2 to 4 justify themselves.
- Workload mix. Thousands of concurrent dashboard users favor engines with mature concurrency and caching. Heavy machine learning feature engineering, unstructured data and large batch transformations favor Spark-centric platforms.
- Data ownership and sovereignty. Regulators and procurement teams increasingly ask where data physically sits and how it can be moved. Storing data in customer-owned buckets in open formats makes switching and residency evidence simpler, which matters under rules such as the EU Data Act’s switching provisions.
- Team skills and capacity. A five-person analytics team should not run a composable lakehouse. A platform team with strong data engineering skills may find warehouse-native constraints frustrating.
- Cost model. Compare total cost, including storage, compute, egress, catalog and maintenance, plus people. Open storage lowers storage costs and avoids duplicate copies; warehouse-native compute is often more efficient for BI concurrency. Model your actual query patterns rather than relying on benchmark claims.
- Governance requirements. Fine-grained masking, row-level security, lineage and auditing must work consistently for every engine that touches sensitive data. In multi-engine designs, verify that policies defined in the catalog are actually enforced by each engine, not just by the primary one.
- AI and agent access. Agents and retrieval pipelines need governed, well-described data. A semantic layer and catalog metadata matter more here than storage format; see making the warehouse AI-ready.
A Practical Decision Path
- List the engines you need in the next three years, not the ones you would like to try. Include BI tools, transformation frameworks, streaming, data science and AI workloads.
- Classify your data by consumer pattern: data used only through SQL and BI, data shared between SQL and Spark or Python, and data that is mostly unstructured or machine learning oriented.
- Decide where the authoritative copy lives. For shared data, prefer open tables in storage you own. For BI-only marts, native warehouse tables are often simpler and faster.
- Choose the catalog deliberately. Pick one primary catalog for governance and make sure every engine can use it, either natively or through the Iceberg REST protocol. Avoid splitting authority over the same tables across catalogs.
- Run a proof of value on real queries. Benchmark your top 20 queries, a representative transformation pipeline and a concurrency test on candidate patterns. Measure cost per run, not just speed.
- Check the exit path. For each option, ask how you would move the data and permissions to another engine in two years, and how long that would take.
Cost, Performance and Governance Trade-offs in Detail
Storage and duplication
Duplicate copies are the hidden cost of the old two-tier design, where data landed in a lake and was then copied into a warehouse. Patterns 2 to 4 remove most duplication by letting engines share tables. The savings are often larger in engineering time, fewer pipelines to maintain and fewer reconciliation issues, than in storage dollars.
Maintenance
Open tables need compaction, snapshot expiry, orphan file cleanup and statistics. Managed offerings now automate much of this, but you must know which service is responsible for each table. Two services both trying to maintain the same table, or neither doing so, are common failure modes in multi-engine designs.
Performance
Warehouse engines are heavily optimized for their native storage, and some optimizations do not yet apply to external Iceberg tables. Lakehouse engines have closed much of the gap for BI, but high-concurrency dashboards still deserve explicit testing. For small and medium datasets, single-node engines can be dramatically cheaper; we explore that in right-sizing big data with DuckDB.
Governance
In a single-engine world, the engine enforces policy. In a multi-engine world, the catalog defines policy and each engine must honor it, often through short-lived credentials vended by the catalog, as Snowflake describes for Horizon. Test this explicitly: create a masked column, query it from every engine and confirm the result.
Worked Example: A Retailer Choosing Its Next Platform
Consider a hypothetical mid-sized retailer running a ten-year-old on-premises warehouse that feeds 400 dashboard users, plus a separate data lake used by a small data science team for demand forecasting. Pipelines copy data between the two, reconciliation is a weekly headache, and leadership wants to add AI assistants for store managers.
The team lists its engines: a SQL engine for BI, a transformation framework, Spark for forecasting features, a streaming path for point-of-sale events and an AI layer that must query governed metrics. It classifies data: finance and merchandising marts are BI-only; sales, inventory and customer tables are shared between BI and data science; product images and documents are unstructured.
The decision is Pattern 2, a cloud warehouse as the primary engine, with shared sales, inventory and customer tables stored as Iceberg in the retailer’s own object storage and governed by the warehouse’s catalog, while BI-only marts stay native for maximum dashboard performance. Spark jobs read and write the shared Iceberg tables through the catalog’s REST endpoint, eliminating the copy pipelines. The proof of value confirms that the top dashboards meet response targets on native marts and that Spark writes respect masking policies. A semantic layer is defined on top for both dashboards and AI assistants. Should the data science workload grow into the center of gravity, the open tables keep a later move toward Pattern 3 or 4 viable without a full data migration.
Migration Playbook and Pitfalls
Whatever pattern you choose, the migration from a legacy warehouse follows similar steps: inventory sources, models and consumers; convert SQL and transformation logic, increasingly with AI assistance, as covered in our guide to AI-assisted SQL conversion; run old and new platforms in parallel with automated reconciliation; and cut consumers over domain by domain.
- Choosing on hype. Picking a composable lakehouse because it is fashionable, without the platform team to run it, produces fragile systems.
- Assuming open means portable. Open file formats help, but permissions, semantic definitions, pipelines and engine-specific SQL also need to move. Plan for all of them.
- Splitting catalog authority. Registering the same tables in two catalogs that both accept writes invites conflicting commits and governance gaps.
- Ignoring small files and maintenance. Streaming into open tables without compaction degrades performance within weeks.
- Skipping concurrency tests. Single-query benchmarks hide the problems that appear on Monday morning when hundreds of users open dashboards at once.
- Leaving the semantic layer for later. Without shared metric definitions, a new platform reproduces the old “which number is right” arguments, and AI assistants amplify them.
Outlook: What to Expect Over the Next Two Years
Several trends are likely to shape these decisions through 2027 and 2028, and they are worth factoring into any platform choice made today.
- Catalog interoperability will matter more than format wars. With Iceberg, Delta Lake and their interoperability layers converging, competition is shifting to catalogs, governance features and how well policies travel between engines. Favor catalogs that implement open protocols such as the Iceberg REST specification.
- Managed maintenance becomes table stakes. As object storage services and warehouses absorb compaction, clustering and snapshot management, the operational gap between warehouse-native and open tables will keep narrowing.
- Agents become a first-class consumer. AI agents querying data on behalf of users will raise the bar for metadata quality, semantic definitions and per-request access control. Platforms that expose governed data through standard interfaces will have an advantage.
- Cost scrutiny intensifies. FinOps practices increasingly track data platform spend by workload and team. Architectures that make cost attribution easy, by workspace, warehouse or job, will be easier to defend.
None of these trends argues for waiting. They argue for choosing an architecture that keeps the authoritative data in open, well-governed tables where it matters, so that engines, tools and even vendors can change around it without another wholesale migration.
Conclusion: Decide on Ownership, Not Labels
The warehouse and the lakehouse have converged to the point where labels say little about what you are buying. What still matters is who owns the storage, which catalog governs it, which engines must share it, how much platform engineering you can sustain and how easily you could change course. For many organizations in 2026, the pragmatic answer is a warehouse or lakehouse platform with open tables for shared data, a single authoritative catalog and a semantic layer on top. Make those choices explicitly, validate them on your own workloads, and the architecture will serve BI, data science and AI without forcing another re-platforming in three years.
How Hanoi Technology Can Help
Hanoi Technology designs and builds warehouse and lakehouse platforms on Snowflake, Databricks, Microsoft Fabric and the major clouds, from architecture decisions to migration and operations.
Further Reading
- Full bidirectional interoperability for Iceberg tables in Snowflake Horizon Catalog – Snowflake
- Iceberg tables: write support by using an external query engine (GA) – Snowflake release notes
- Apache Iceberg managed tables in BigQuery – Google Cloud
- Amazon S3 Tables now support automatic replication of Apache Iceberg tables – AWS