What is a data lakehouse? Architecture, benefits, and examples
Updated Oct 30, 2026
A data lakehouse is a data architecture that combines the flexible, low-cost storage of a data lake with the data management and analytical capabilities associated with a data warehouse. It stores structured, semi-structured, and unstructured data in open formats and adds a metadata layer so that data can be queried, governed, and trusted.
The need for this architecture grows as more teams depend on the same data. A data engineering team may want raw unstructured data, such as PDFs and images, to build AI capabilities. A RevOps team needs structured ERP data for business reporting. Serving both from separate systems means separate ingestion processes, duplicated data, and governance that is harder to keep consistent.
A lakehouse gives these workloads a shared, governed foundation for BI, analytics, and AI/ML. This guide explains how a data lakehouse works, how it compares with data lakes and data warehouses, its benefits, and practical enterprise examples.
How does a data lakehouse work?
A lakehouse brings together five functions: data ingestion, storage, metadata and table management, processing, and analytical consumption. Data from enterprise applications and other sources lands in shared cloud storage. A table layer organizes it, and query engines serve it to the people and tools that need it.
Data ingestion and cloud object storage
Structured data from ERP and CRM systems, semi-structured data such as JSON events, and unstructured data such as documents and images enter the lakehouse through ingestion pipelines. The data is stored in cloud object storage, such as Amazon S3, Azure Data Lake Storage (ADLS), or Google Cloud Storage (GCS), which offers low cost storage at large scale.
Storage and compute are separated. Data stays in one place, and teams scale the compute resources for each workload independently, so a nightly finance report and a model training job do not compete for the same capacity.
Ingestion design determines how useful that data is. Teams need to decide how fresh each dataset must be, how records are validated before they land, and how pipelines respond when a source application adds a field or changes a data type. Unmanaged schema drift is a common reason downstream reports break. For more on pipeline design, see Celigo’s guide to data ingestion pipelines.
Metadata, open table formats, and governance
Object storage on its own holds files, not tables. Data is often stored in Apache Parquet, an open columnar file format that is efficient for analytics. A table format then adds metadata on top of those files so that query engines can treat them as reliable tables.
The three most common open table formats are Delta Lake, Apache Iceberg, and Apache Hudi.
Each tracks which files belong to a table and supports:
- ACID transactions, so concurrent reads and writes do not leave a table in a partial state
- Schema enforcement and evolution, so bad records are rejected and columns can be added without rewriting a table
- Time travel, so teams can query or restore an earlier version of a table for audits and reproducible analysis
Governance sits on top of this layer. A catalog, such as Unity Catalog or Apache Polaris for Iceberg, manages access controls, data lineage, and discovery across tables. This is how a lakehouse avoids the data silos and “data swamp” problems that unmanaged data lakes can create: data quality rules and permissions are defined once and applied to every workload that reads the table.
Data processing and serving
Query and processing engines read the tables and prepare data for consumption. Apache Spark is widely used for large-scale transformation and machine learning, while SQL engines such as Databricks SQL, often accelerated by vectorized engines like Photon, serve BI dashboards and ad hoc queries.
Many teams organize data with a medallion architecture, an optional design pattern with three layers:
- Bronze: raw data landed from source systems, close to its original form
- Silver: cleansed, matched, and conformed data
- Gold: curated, consumption-ready datasets for specific reports or models
The medallion architecture gives each layer a clear purpose, which makes it easier to trace a figure in a dashboard back to the raw data that produced it.
Data lakehouse vs. data lake vs. data warehouse
Data lakes prioritize flexible storage for every data type. Data warehouses provide managed analytical capabilities for structured data. Lakehouses combine flexible storage with table management, governance, and analytical processing.
| Factor | Data lake | Data warehouse | Data lakehouse |
|---|---|---|---|
| Storage and compute | Low-cost object storage; compute added separately | Managed storage and compute, often proprietary | Object storage with independently scaled compute |
| Schema and transactions | Schema-on-read; limited transaction support | Schema-on-write with ACID transactions | Open table formats add ACID transactions and schema enforcement |
| Governance and reliability | Can be difficult to govern at scale | Mature governance and data quality controls | Catalog-based governance and lineage across open data |
| Typical workloads | Data science, ML, raw data exploration | BI, reporting, SQL analytics | BI, SQL analytics, data science, and ML on shared data |
| Cost and operations | Low storage cost; more engineering effort to manage | Higher cost for large or unstructured data volumes | Low storage cost; requires table and catalog management |
The right choice depends on an organization’s requirements and existing infrastructure. Modern data warehouses increasingly support semi-structured data and AI workloads, and many lakehouse deployments run alongside a warehouse rather than replacing it.
The benefits of a data lakehouse
A lakehouse addresses the problems created by running separate ingestion processes, separate storage destinations, and separate governance for each workload.
- Simplified data ingestion. When multiple workloads share the same analytical storage, teams can maintain fewer ingestion destinations and fewer unnecessary copies of the same data. Ingestion pipelines are still required, but each source can be loaded once and reused by reporting, data science, and AI teams instead of being reprocessed for each.
- Potentially lower storage costs. Cloud object storage is generally less expensive than warehouse storage, and data can be tiered by importance and access frequency, with rarely used history moved to cheaper storage classes. Total cost also depends on compute, data movement, and the effort required to maintain tables and pipelines, so savings vary by workload.
- A single source of truth for analytics. Shared, governed datasets improve consistency and reduce redundant analytical copies, so finance and sales teams report from the same numbers. ERP, CRM, and other operational systems remain authoritative for their own records; the lakehouse is the shared source for analysis, not a replacement for those systems.
- Agility and flexibility. Teams can use their preferred tools and engines on the same data, scale compute independently for each workload, and support BI, streaming, and machine learning without moving data between systems. Governed metadata and table management add reliability, so that flexibility does not come at the cost of data quality.
Adoption reflects these benefits. In Dremio’s 2026 State of the Data Lakehouse & AI report, 81% of surveyed data leaders cited eliminating redundant data copies as a top priority, and 78% planned to run AI/ML workloads directly on the lakehouse.
Data lakehouse examples and use cases
Shared analytical data can serve very different enterprise workloads. The examples below show what teams do with a lakehouse once data is ingested and governed.
Business intelligence and enterprise reporting
A RevOps team wants a unified view of revenue. NetSuite financial records and Salesforce opportunity data are ingested into the lakehouse, joined in curated gold tables, and used for business intelligence dashboards and revenue forecasting. Analysts query consistent data with SQL instead of reconciling spreadsheet exports from two systems.
The source applications retain ownership of their operational records. If an invoice amount is wrong, it is corrected in NetSuite, and the corrected record flows into the lakehouse on the next sync.
Machine learning and AI
The same lakehouse can store the PDFs, support transcripts, and images that data scientists use for AI, alongside structured enterprise data. A churn prediction model, for example, can combine usage events, support ticket text, and billing history from the ERP. The lakehouse manages and versions the training data, while model execution happens in ML tools such as MLflow or a separate serving platform. Keeping data management and model execution distinct makes it easier to reproduce a model’s results using time travel on the exact data it was trained on.
Example data lakehouse technology stack
A representative enterprise stack might look like this: Enterprise sources (ERP, CRM, ecommerce) → ingestion → object storage (Amazon S3) → table formats and metadata (Parquet files managed as Apache Iceberg or Delta Lake tables, governed by a catalog) → processing engines (Apache Spark, Databricks) → BI and AI (dashboards, Databricks SQL, ML models) Other combinations work as well. Snowflake, for example, now supports Iceberg tables, and AWS offers S3 Tables with built-in Iceberg support. The components are interchangeable because the formats are open, which is a large part of the lakehouse’s appeal.
Support data lakehouse workflows with Celigo
A lakehouse is only as useful as the data that reaches it. Operational data lives in dozens of applications, each with its own APIs, schemas, and update patterns, and moving it reliably is a recurring engineering burden.
Celigo Data Ingestion, part of Celigo’s Intelligent Automation Platform, helps move operational data from supported SaaS applications, ERPs, databases, and file sources into analytical destinations. Syncs start with a historical backfill, then load changes incrementally, detect schema drift when source fields or tables change, and surface issues through monitoring and alerts. The broader platform connects enterprise systems and coordinates data movement and business workflows, and separate integration and reverse ETL capabilities can activate trusted analytical data back into operational applications.
Consider the RevOps example above. Celigo can ingest NetSuite financial records and Salesforce opportunity data into a supported destination, such as Snowflake, for FP&A reporting, and then activate relevant insights back into Salesforce. Snowflake is one supported analytical destination, not necessarily a complete lakehouse architecture.
Storage, table formats, metadata management, and query processing are provided by the destination platform, while Celigo handles reliable data movement into and out of it.
Explore Celigo Data Ingestion to see how it supports reliable data movement into your analytical environment.
