Skip to content
The Modern Data Stack

01.03 · Short

Lakehouse Architecture Overview

Identify when to use object storage, table formats, compute engines, catalogs, and warehouses in a lakehouse architecture.

A lakehouse splits object storage, table metadata, compute, catalogues, and sometimes a warehouse into separate architectural roles. Use object storage for scalable shared data, table formats for governed files, compute engines for workload-specific processing, catalogues for discovery and policy, and warehouses for polished SQL reporting and operational analytics.

What this lesson answers

  • when should I use a data lakehouse
  • lakehouse object storage versus warehouse roles
  • what does a lakehouse catalogue do

Notes

A lakehouse architecture separates storage, metadata, and compute so teams can store large amounts of raw and refined data cheaply while still supporting reliable analytics and machine learning workloads. Object storage, such as S3, ADLS, or GCS, is usually the foundation because it is durable, inexpensive, and scales independently of compute. It is the right place for raw events, logs, batch extracts, and curated datasets that need to be shared across multiple tools.

Common questions

What problem does a lakehouse architecture solve?
It lets teams keep large raw and curated datasets in cheap, durable storage while still adding structure for analytics and machine learning. Instead of binding data to one query system, the architecture separates storage, metadata, and compute so different engines can work over the same governed tables.
Why are table formats needed on top of object storage?
Object storage is good at holding files, but poor at behaving like a database table by itself. Formats such as Delta Lake, Apache Iceberg, and Apache Hudi add schemas, partitions, transactional updates, historical reads, and safer concurrent access, which makes shared files usable for production analytics.
Does a lakehouse replace the data warehouse?
Not always. A warehouse can still be the right place for fast SQL, managed workloads, semantic models, governance, and business reporting. The lakehouse is often the shared data foundation, while the warehouse serves high-quality analytics experiences where performance and user-facing reliability matter most.