A data lakehouse is a data platform that stores data as open-format files in low-cost object storage, while providing the transactional guarantees, schema management and query performance previously available only in a data warehouse. It is made possible by open table formats — Apache Iceberg, Delta Lake, Apache Hudi — which add a metadata layer over those files that gives engines a consistent, versioned view of a table.

The short version of why it exists: warehouses gave you reliability but locked your data inside a proprietary engine at high cost. Lakes gave you cheap open storage but no guarantees, and most became unusable. The lakehouse is the attempt to keep the first property without paying for the second, and the reason it now works is that the table formats matured.

That maturity is no longer in question. By Iceberg Summit 2026 — over 600 attendees and more than 70 sessions — not a single talk was arguing for adoption; every session assumed the audience was already running it. The interesting question moved from which format to what to build on top.

How we got here

Worth understanding, because the trade-offs of each generation explain what the lakehouse is actually optimising for.

The data warehouse

Structured, schema-on-write, heavily optimised for SQL analytics. Data is loaded through ETL pipelines that clean and conform it before it lands.

What it did well: ACID transactions, consistent performance, mature governance and access control, a query interface every analyst already knew.

Where it broke: storage and compute were coupled and both were expensive, so cost scaled with volume in a way that forced organisations to discard data they might later have wanted. Schema-on-write meant every new question required a pipeline change, and pipeline changes required an engineering queue. Data was stored in a proprietary format, so using it with anything other than the warehouse meant copying it out. And it handled only structured data.

The defining symptom: an analytics backlog measured in months, where every new question is a project.

The data lake

The reaction. Store everything, in open formats, on cheap object storage, schema-on-read. Decide what it means later.

What it did well: cheap at any scale, any data type, open formats, storage decoupled from compute.

Where it broke: almost everywhere else. No transactions, so concurrent writes corrupted data. No schema enforcement, so files drifted apart. No reliable way to update or delete a record — which made regulatory deletion requests genuinely difficult. Poor query performance without significant engineering. And no catalog, so nobody could find anything.

The result was the data swamp: petabytes of files nobody trusted, queried through jobs only three people understood.

The lakehouse

The synthesis. Keep the lake's storage economics and openness. Restore the warehouse's guarantees by adding a metadata layer.

The key insight is that a table does not have to be a proprietary storage structure. It can be a set of files plus a manifest describing which files constitute the table at a given point in time. Once you have that manifest, you can add atomic commits, schema evolution, time travel and partition management — while the underlying data stays as ordinary Parquet files that any engine can read.

That manifest layer is the open table format, and it is the entire technical foundation of the lakehouse.

What the table format actually provides

The four capabilities that turn a directory of files into a table.

Atomic commits. A write either becomes visible in full or not at all. Readers never see a half-written state. This is what makes concurrent access safe, and its absence is what made data lakes unreliable.

Schema evolution. Add, drop, rename or reorder columns without rewriting the data. The format tracks column identity independently of position, so a rename does not silently break every downstream query.

Time travel and snapshots. Every commit produces a snapshot. You can query the table as it was at a timestamp, roll back a bad write, and reproduce a report exactly as it ran last quarter. In a regulated institution this is not a convenience feature — it is how you answer questions about historical figures.

Row-level updates and deletes. Essential for change data capture, for corrections, and for deletion obligations under data protection law. Plain file-based lakes could not do this without rewriting entire partitions.

Where the formats stand in 2026

Iceberg has won the neutrality argument. It is engine-agnostic by design, and Snowflake, AWS, Google and the broader open-source ecosystem have converged on it as the common standard, while Databricks — which created Delta Lake — has added substantial Iceberg compatibility through Unity Catalog.

Two developments from 2026 are worth knowing before you commit to an architecture:

Practical advice is unchanged and now better supported: choose Iceberg where engine independence matters, and pay attention to which catalog you are committing to.

The lakehouse compared

Reading each dimension across the three, warehouse first, then lake, then lakehouse:

  • Storage cost — high, low, low.
  • Format — proprietary, open, open.
  • Transactions — yes, no, yes.
  • Schema handling — on write, on read, either and enforced.
  • Updates and deletes — yes, impractical, yes.
  • Unstructured data — no, yes, yes.
  • Engine choice — locked to the vendor, any engine, any engine.
  • Time travel — limited, none, full snapshots.
  • Performance — excellent, poor, good to excellent.
  • Operational complexity — low, high, moderate.

The row that matters most commercially is engine choice. In a warehouse, your data is inside the vendor's system and moving it is a migration. In a lakehouse, the data is Parquet files in your object store, and the query engine is a component you can replace. That is a durable structural advantage, and it is why organisations that have been through one expensive warehouse migration tend to insist on it.

Federation: the piece that makes it practical

The honest problem with any lakehouse plan is that you already have twenty systems, and moving all of them into the lakehouse is a multi-year programme that will not survive a change in priorities.

Query federation solves this. A federated engine — Trino and its commercial distribution Starburst being the dominant option — queries data where it lives, joining across the lakehouse, the existing warehouse, operational databases and object storage in a single SQL statement, without moving anything. Trino ships more than 30 production-grade connectors and Starburst extends that to 50 or more.

This changes the migration story completely. Instead of a big-bang move, you place the federated engine over the estate as it is, deliver value immediately, and migrate individual datasets into the lakehouse when there is a specific reason to — performance, cost or governance — rather than because a plan says so.

The mechanics are covered in what is data virtualization, and the regional context in Starburst and Trino in Azerbaijan.

Reference architecture

A working lakehouse has five layers.

Storage. Object storage — S3-compatible, including on-premise implementations such as MinIO or Ceph for organisations that cannot use public cloud. Data as Parquet.

Table format. Iceberg, most commonly, providing the transactional layer over those files.

Catalog. Two distinct things share this word, which causes constant confusion:

  • A technical catalog the engines use to resolve table metadata — Hive Metastore, or a REST catalog such as Apache Polaris or Nessie.
  • A business catalog for governance — what the data means, who owns it, where it came from. That is OvalEdge and it is a different concern.

You need both. Conflating them is a recurring source of confused architecture diagrams.

Query engine. Trino or Starburst for federated and interactive SQL; Spark for heavy batch transformation. These coexist against the same tables, which is the point of an open format.

Consumption. BI tools, notebooks, applications and AI retrieval, all speaking SQL against the same governed tables.

What it costs — and what it costs you

Where it saves. Storage costs a fraction of warehouse storage. Compute is decoupled and scales with actual query load. There is no proprietary format lock-in, so future engine changes are configuration rather than migration. Federation removes entire categories of pipeline that existed only to move data between systems.

Where it costs. Operational complexity is genuinely higher than a managed warehouse — you are assembling components rather than buying one product. Small-file management, compaction and partition maintenance are real ongoing tasks, and they get harder as workloads move away from what Iceberg was originally designed for: streaming pipelines committing every few seconds and feature tables with thousands of columns are now common, and they stress the metadata layer. Query performance on the hardest workloads still trails a well-tuned dedicated warehouse. And the skills are less common in this market than warehouse skills.

When not to build one

Worth stating plainly, because the architecture is fashionable and fashion is a poor reason.

Your data fits comfortably in one database. Under a few terabytes, with a single team and predictable queries, a well-run PostgreSQL or a managed warehouse is simpler, faster and cheaper. Building a lakehouse here is expensive theatre.

You have no data engineering capability. A lakehouse is assembled from components. Without someone to own it, it degrades into the swamp it was designed to prevent.

Your workload is purely operational. Lakehouses are analytical infrastructure. High-concurrency, low-latency transactional serving is a different problem.

The real problem is governance. If the difficulty is that nobody trusts the numbers, a new storage architecture will not fix that. It will reproduce the same confusion on cheaper storage. Governance first — see data governance in Azerbaijan.

A sensible migration path

For an organisation with an existing warehouse and pipeline backlog:

  1. Federate first. Put a query engine over the existing estate. Immediate value, no migration, and it tells you what people actually query.
  2. Land new data in the lakehouse. New sources go to object storage as Iceberg tables. No migration required, and the lakehouse grows organically.
  3. Move datasets with a reason. The largest, most expensive tables in the warehouse, and anything needing history you cannot currently afford to keep.
  4. Reduce the warehouse to what it is genuinely best at. It may remain the right home for high-concurrency serving. Cost falls with scope.
  5. Govern throughout. Catalog and lineage across both, from the start, so the lakehouse is governed from day one rather than retrofitted.

This sequence delivers value in the first quarter and never requires a big-bang cutover — which is why it survives the leadership changes and budget cycles that kill multi-year migration plans.

Key points

  • A lakehouse is open-format files in object storage plus a table format that restores transactions, schema evolution and time travel.
  • The format debate is settled in practice: Iceberg is the neutral standard, and 2026 brought metadata convergence with Delta plus a top-level Apache catalog project in Polaris.
  • Watch the catalog, not just the file format. That is where lock-in reappears.
  • Engine choice is the durable commercial advantage: your data is not inside a vendor's system.
  • Federation is what makes a lakehouse practical without a multi-year migration. Federate first, migrate selectively.
  • Distinguish the technical catalog from the business catalog. They are different tools solving different problems.
  • If your data fits in one database, or your real problem is governance, do not build one.

Yukon Labs implements Starburst on Trino for federated lakehouse analytics, deployed on-premise where required.