TL;DR: The table-format question has largely settled — Apache Iceberg is the default open choice for new lakehouse builds in 2026, with every major platform (Snowflake, Databricks via UniForm, AWS S3 Tables, Google BigQuery) now reading and often writing it. The battle has moved up the stack to the catalog layer (Polaris, Unity Catalog, Glue) and to the more fundamental question of whether you need an open lakehouse at all versus a managed warehouse. This article walks through how we'd actually make that call for a given workload, not just which table format wins a feature comparison.

"Lakehouse vs. warehouse" gets debated as a religious question when it's really an operational one: how much do you value engine flexibility and avoiding lock-in versus how much do you value minimal operational burden and predictable BI concurrency. Both are legitimate priorities, and the right answer depends on your workload mix, your team's existing skills, and how many different engines actually need to touch the same data. Here's the framework we use.

The table format question is mostly decided: Iceberg

Apache Iceberg was designed as a vendor-neutral specification first, implementation second — and that design choice is why, in 2026, every major platform reads and increasingly writes it: AWS via S3 Tables (a managed, native Iceberg storage primitive with cross-region replication), Snowflake via both external and managed Iceberg tables, Google via BigQuery, and even Delta Lake's own creator, Databricks, via UniForm compatibility. Iceberg v3 closed most of the remaining feature gaps against Delta Lake — deletion vectors, row lineage, and a native VARIANT type for semi-structured data.

Delta Lake remains the right default if your organization's world is genuinely Databricks-centric or built around Microsoft Fabric — its tooling integration there is deeper, and UniForm gives you Iceberg-readable compatibility for the cases where an external engine needs to read the same tables. Technically, the two formats differ in how they track table state: Iceberg uses a tree of manifest files, Delta Lake uses a JSON-based transaction log with periodic Parquet checkpoints. One practical difference that matters in production: Iceberg handles partition scheme evolution without a full table rewrite, where Delta Lake historically required one — a real operational cost if your partitioning strategy is likely to change as data volume grows.

Apache Hudi remains a strong option specifically for high-frequency upsert/merge workloads (CDC-heavy pipelines with constant row-level updates), where its incremental-processing design gives it an edge, but it has a smaller ecosystem of engine support than Iceberg or Delta in 2026.

For a new build with no strong existing Databricks investment: default to Iceberg. It's the safer bet for multi-engine flexibility and is where the ecosystem's investment is concentrated.

The real battleground moved to the catalog layer

Format interoperability being mostly solved means the question that actually determines your architecture today is: which catalog controls table metadata, access, and governance across every engine that touches your data? This is where meaningful lock-in still lives, even on top of an open table format.

Three approaches compete in 2026:

  • Apache Polaris — an open, REST-catalog-spec implementation that graduated to a top-level Apache project in early 2026. Vendor-neutral by design, growing fast as the community answer to "an open catalog that isn't tied to one platform vendor."
  • Unity Catalog (Databricks) — originally Databricks-specific, now open-sourced and extended to govern Delta, Iceberg, and Hudi tables plus unstructured volumes, functions, and ML models under one governance layer. The strongest choice if you're already deep in the Databricks ecosystem and want unified governance across data and ML assets.
  • AWS Glue / S3 Tables — AWS's native path, with the Iceberg REST protocol wired directly into Glue and S3 Tables, giving a managed, low-ops catalog option for AWS-centric shops that don't want to operate catalog infrastructure themselves.

The practical decision rule: if you're multi-cloud or want to keep long-term optionality, weight toward a REST-catalog-spec-compliant option (Polaris, or any catalog implementing the open REST protocol) over a single vendor's proprietary catalog — the REST catalog spec is exactly the layer designed to prevent catalog lock-in from replacing the table-format lock-in the industry just spent years solving.

Lakehouse vs. managed warehouse: the actual decision

With the format question mostly settled, the higher-level decision is whether you need an open lakehouse architecture at all, or whether a managed warehouse (Snowflake, BigQuery, Redshift) with native Iceberg support gives you enough of the benefit without the operational overhead of running lakehouse infrastructure yourself.

Lean toward an open lakehouse (Iceberg + a REST catalog + your choice of query engines) when:

  • Multiple engines genuinely need to query the same data — a Spark-based ML pipeline, a Trino-based ad hoc analytics layer, and a BI tool all hitting the same tables without copying data between systems.
  • You want to avoid vendor lock-in as an explicit, weighted priority, not just a nice-to-have.
  • You have (or are building) the platform engineering capacity to run catalog infrastructure, handle compaction and maintenance jobs, and manage access control across engines yourselves.
  • Your workload mix includes heavy engineering/AI workloads where pipeline-level optimization matters more than BI-query predictability.

Lean toward a managed warehouse when:

  • BI concurrency and query predictability for a relatively fixed set of dashboards and analysts is the dominant workload, and minimizing operational burden matters more than engine flexibility.
  • Your team doesn't have (and doesn't want to build) dedicated data platform engineering capacity.
  • A single vendor's native Iceberg support already gives you enough external-engine interoperability for the occasional cases where something outside the warehouse needs to read the data — you get most of the openness benefit without running the catalog and compaction machinery yourself.

These aren't mutually exclusive in practice — a common 2026 pattern is a managed warehouse for BI and predictable analyst workloads, with an open Iceberg lakehouse layer underneath (or alongside) for engineering and ML workloads, connected via native Iceberg reads so both worlds share ground truth rather than maintaining separate copies.

sql
-- example: Snowflake querying a managed Iceberg table
-- backed by S3, catalog integration via Glue or a REST catalog
CREATE ICEBERG TABLE events
  CATALOG = 'glue_catalog'
  EXTERNAL_VOLUME = 'iceberg_ext_vol'
  BASE_LOCATION = 's3://data-lake/events/';

SELECT event_type, COUNT(*)
FROM events
WHERE event_date >= DATEADD(day, -7, CURRENT_DATE())
GROUP BY event_type;

Migration and maintenance realities

Moving an existing warehouse-native dataset into an Iceberg-backed lakehouse isn't free, and the ongoing operational cost is worth budgeting for honestly, not glossing over in the initial architecture pitch:

  • Compaction and file management. Iceberg tables accumulate small files under continuous write load the same way any columnar-on-object-storage format does; without scheduled compaction jobs, query performance degrades over months, not immediately — which makes it an easy thing to under-provision for early on and regret later.
  • Metadata growth. Manifest files and snapshot history grow with table activity; expiring old snapshots on a schedule (rather than never) keeps catalog operations fast and storage costs bounded.
  • Catalog migration cost is real but bounded. If you start on one catalog (say, AWS Glue) and later want to move to an open REST catalog like Polaris for multi-cloud reasons, the fact that both speak the same underlying Iceberg table format makes this materially less painful than a full table-format migration would have been — this is precisely the interoperability the open-format bet is supposed to pay off.

Query engine choice compounds the decision

Picking a table format and catalog doesn't fully determine your architecture — the query engines sitting on top matter just as much for day-to-day experience. Trino and Spark remain the workhorses for large-scale batch and interactive SQL across Iceberg tables; DuckDB has moved from a laptop-analytics curiosity to a genuinely production-relevant engine, now with full read-and-write support against Iceberg including UPDATE and DELETE, which makes it a viable lightweight option for smaller teams that don't want to stand up a Spark or Trino cluster just to query a few terabytes. Snowflake and BigQuery both now read (and increasingly write) Iceberg natively, which is what makes the hybrid pattern described above — managed warehouse for BI, open lakehouse underneath for engineering — practical rather than theoretical: the warehouse isn't a separate copy of the data, it's another engine reading the same Iceberg tables through its own optimized path.

The practical implication: don't lock the engine decision in at the same time as the format and catalog decision. An open table format's entire value proposition is that the engine layer can evolve independently — a team that commits hard to one engine's proprietary features on top of an otherwise-open format has quietly recreated the lock-in the format choice was meant to avoid.

Syslabs' data engineering team designs lakehouse and warehouse architectures as part of our data analytics & BI work — happy to talk through your specific workload mix.

Sources: Dremio: Apache Iceberg vs Delta Lake, Lakehouse Table Formats in 2026 — substack, The State of Apache Iceberg Catalogs in June 2026, Databricks vs. Snowflake in 2026: Architecture-Level Guide