What Is a Data Lakehouse? How It Works in 2026

Data lakehouses merge scalable object storage with structured governance, giving teams one place to run both reporting dashboards and machine learning models. This article covers the core architecture, compares lakehouses to traditional warehouses and lakes, and walks through the benefits, challenges, and use cases that matter most in 2026.

Key takeaways: data lakehouse

Here are the core points to keep in mind as you evaluate a data lakehouse:

• Definition: A data lakehouse combines the low-cost storage of a data lake with the structure and governance of a data warehouse, all on one copy of data.
• Where it fits: The lakehouse sits between raw data ingestion and your analytics tools, serving as the governed foundation for both BI dashboards and AI models.
• Common misconception: A lakehouse is not a product you buy. It is an architectural pattern built on open table formats and a metadata catalog.
• What's changing: AI workloads, now used by 88 percent of organizations according to McKinsey, and multi-engine access are pushing lakehouse adoption well past traditional reporting use cases. That adoption rate signals a shift: organizations aren't just experimenting with AI anymore. They need governed data foundations that can support production workloads.

What is a data lakehouse

A data lakehouse is a data architecture that merges the scalability of a data lake with the management capabilities of a data warehouse. Think of it as one storage layer where raw files, structured tables, and machine learning (ML) features all live together (governed, queryable, and versioned).

The architecture relies on open file formats like Parquet, managed by open table formats that add transaction logs and schema controls on top of object storage. A metadata catalog enforces governance, and compute engines query the data in place.

Databricks, Snowflake, Google BigQuery, and others offer lakehouse-compatible platforms. The architecture itself stays vendor-agnostic when you build on open formats. Here's what actually qualifies: if your BI and ML tools can read the underlying storage directly with full transaction support, without copying data into a separate proprietary warehouse layer, you have a lakehouse. Simply storing data in Parquet files? That doesn't cut it. The transaction log and metadata layer are what distinguish a lakehouse from a well-organized lake.

Four components make this work:

• Open table formats: Add ACID transactions and schema management to raw files.
• Unified storage: One copy of data serves BI, ML, and operational workloads.
• Separation of storage and compute: Scale each independently based on what you need.
• Governance at the table level: Row-level security, column masking, and lineage apply consistently across tools.

How data lakehouse architecture works

Without a transaction log, concurrent writes corrupt data and BI queries return inconsistent results. The lakehouse architecture solves this by adding structured layers on top of raw storage.

Ingestion layer

Batch and streaming pipelines land data in object storage. This layer handles change data capture, file format conversion, and initial quality checks. Skip it, and raw files pile up without structure. Classic data swamp.

The ingestion layer is also where teams keep a lakehouse usable at scale by automating freshness. Incremental loads sync only changed records. Event-based triggers run when a source system changes. Both help keep tables current without running full reloads every night.

Storage layer

Object storage holds all data in open file formats. Cost scales with volume, not compute. But object storage alone lacks transactional guarantees, which is where the metadata layer comes in.

Metadata layer

Open table formats add transaction logs, schema enforcement, and time travel to files in storage. This layer enables ACID (atomicity, consistency, isolation, durability) transactions, preventing partial writes, enforcing schema evolution, and allowing rollback to prior versions.

API and query layer

SQL (structured query language) engines, Spark, and other compute engines read the metadata layer to query data in place. You scale query capacity without duplicating data.

Consumption layer

BI dashboards, ML pipelines, and operational apps connect here. All workloads read from the same governed tables, so there is no need to copy data into separate systems.

Profile your storage layer weekly. If you see thousands of kilobyte-sized files, your ingestion layer needs tuning before query performance tanks.

Core features of a data lakehouse

A vendor may claim lakehouse capabilities, but if the platform requires copying data to a separate warehouse for BI, the architecture is closer to a data lake plus a separate warehouse layer than a lakehouse.

True lakehouses share these features:

• Open file and table formats: Data stays in open formats, preventing vendor lock-in and letting multiple engines read the same data without conversion.
• ACID transactions: Transaction logs ensure atomicity, consistency, isolation, and durability. Partial writes cannot corrupt tables, and concurrent queries do not conflict.
• Schema enforcement and evolution: The metadata layer rejects writes that violate the table schema while supporting evolution. You can add columns or change types without rewriting entire tables.
• Unified governance: Row-level security, column masking, and lineage apply at the table level, not per-tool. One policy governs access for analysts, data scientists, and downstream applications.
• Streaming support: Lakehouses ingest streaming data alongside batch with the same ACID guarantees. Near-real-time dashboards and ML features use the same governed tables.

Data lakehouse vs data warehouse vs data lake

Should you consolidate on a lakehouse or maintain separate systems? That depends on your workloads, governance needs, and budget.

Data warehouse

Choose a warehouse when your workloads are primarily reporting, your data is structured, and you need strict concurrency guarantees. Warehouses excel at sub-second dashboard queries but often require data movement for ML workloads.

Data lake

Choose a lake when cost is the primary constraint and governance can be handled externally. Lakes become swamps without discipline. Metadata management and quality checks stay manual.

Data lakehouse

Choose a lakehouse when BI and ML share the same data and governance must be consistent across use cases. Query performance may require tuning that warehouses handle automatically, but you avoid duplicating data between systems.

For many teams, the lakehouse conversation is also a hybrid conversation. Data might live across on-prem systems and cloud platforms, and the lakehouse pattern works best when connectivity and governance hold up across those environments.

Benefits of a data lakehouse

A lakehouse eliminates the cost and complexity of maintaining separate lake and warehouse systems.

• Direct BI access without data movement: BI tools query tables in object storage via SQL endpoints, eliminating ETL jobs that copy data to a warehouse.
• Cost-effective storage at scale: Object storage costs a fraction of warehouse storage. Compute scales independently, so you pay for queries only when running them.
• Unified governance for BI and ML: Row-level security and column masking apply at the table level. One policy governs access for analysts and data scientists.
• Reduced data duplication: One copy of data serves dashboards, model training, and operational apps. No sync jobs, no quality drift.
• Streaming and batch in one architecture: ACID transactions apply to both batch loads and streaming ingestion.

Common challenges of a data lakehouse

Lakehouses solve the two-system problem but introduce operational complexity that warehouses abstract away. This is where day-2 operations, tuning, and governance discipline start to matter.

Small files and compaction overhead

Streaming ingestion creates many small files, which degrade query performance. Schedule compaction jobs to merge small files into larger ones. Most table formats automate this, but you need to monitor and tune thresholds. Default settings rarely work well for high-volume streaming workloads.

Query performance tuning

Unlike warehouses that auto-optimize, lakehouses require manual tuning: partitioning strategies, ordering, caching. Start with date-based partitioning for time-series data. Add advanced ordering on high-cardinality filter columns only after profiling query patterns.

Governance consistency across engines

Multiple engines querying the same tables can bypass catalog-enforced policies if not configured correctly. Centralize governance in a single catalog and enforce that all engines authenticate through it.

If compliance is on the line (think Service Organization Control 2 (SOC 2), HIPAA, or GDPR), governance also needs to show its work. Audit trails, encryption in transit, and role-based access control help teams prove who accessed what data, when, and why.

Skill gaps

Lakehouse architectures require skills across data engineering, platform operations, and governance. A broader set than traditional analytics teams possess. McKinsey found that even among high performers, 70 percent report difficulties with data governance and integrating data into AI models quickly. That number matters because it reveals a gap between lakehouse ambition and organizational readiness. Even well-resourced teams struggle with governance at scale. Start with managed platforms that abstract infrastructure and build expertise incrementally.

Cost governance at scale

Object storage is cheap, but compute costs spike with inefficient queries or over-provisioned clusters. Implement query cost tagging, set cluster auto-termination policies, and review expensive queries weekly.

Data lakehouse use cases

Lakehouses excel when reporting and ML workloads share the same underlying data.

Real-time streaming analytics

Dashboards often refresh hourly because batch jobs copy data from a lake to a warehouse. Ingest streaming data directly into lakehouse tables with ACID guarantees, and BI tools query the same tables with sub-minute latency. Operations teams see inventory levels or system health in near-real-time without separate streaming infrastructure.

Unified BI and ML on shared tables

Data scientists frequently export warehouse data to a lake for training, creating governance gaps and stale features. Both dashboards and ML pipelines can read from the same governed lakehouse tables. Feature freshness improves, governance applies consistently, and storage costs drop.

Customer 360 and personalization

Customer data lives in CRM, web analytics, and transactional systems, each with its own schema. Ingest all sources into a lakehouse with unified governance. Apply row-level security so marketing sees aggregates while data science accesses individual records.

Embedded analytics for partners and customers

Some teams build a lakehouse and then hit a funny wall: the data is centralized, but the value is still trapped inside internal dashboards.

When curated lakehouse metrics feed embedded analytics, external stakeholders (customers, partners, franchisees) can access governed dashboards through portals and apps. The embedded experience still respects the same access controls and definitions used internally.

{{custom-cta-1}}

How data lakehouses prevent data swamps

A data lake becomes a swamp when files accumulate without metadata, quality checks, or access controls.

Catalog-enforced access controls

Row-level security and column masking apply at the catalog layer, so every engine respects the same policies. Personally identifiable information (PII) columns are masked for analysts but visible to compliance officers, enforced regardless of whether the query runs in Spark or a BI tool.

Schema enforcement on write

The metadata layer rejects writes that violate the table schema. A pipeline that sends a string to an integer column fails at ingestion, not downstream in a dashboard.

Automated data quality checks

Quality rules run at ingestion or on a schedule, flagging or quarantining bad records. Duplicate customer IDs trigger an alert before they corrupt a core table.

Lifecycle management and retention policies

Tables include retention rules that archive or delete data after a defined period. Raw event logs older than 90 days move to cold storage; aggregates remain in hot storage for dashboards.

AI and ML in a data lakehouse

Traditional architectures required copying data from warehouses to lakes for training. Lakehouses eliminate this by serving both analytics and ML workloads from the same governed tables.

ML frameworks read directly from lakehouse tables via application programming interfaces (APIs) or SQL. No export jobs. No stale copies. This proves especially valuable for feature engineering, where freshness matters.

Row-level security and lineage apply to training data, so models inherit the same access controls as dashboards. This prevents models from training on data people should not see.

Feature stores built on lakehouse tables share the same governance and versioning as reporting data. Time travel enables reproducibility. You can retrain a model on the exact features from a prior date.

In many enterprise stacks, model training and tracking happens in tools tied to the lakehouse layer, such as MLflow in Databricks or Vertex AI in Google Cloud. The important part for the lakehouse pattern is simple: model inputs and outputs stay close to governed tables, so the path from experiment to production has fewer handoffs.

Emerging platforms support vector embeddings alongside structured data, enabling retrieval-augmented generation (RAG) for large language model applications.

How Domo works with data lakehouse architectures

Teams adopting lakehouse architectures need analytics tools that query tables directly, apply consistent governance, and enable self-service without requiring data movement.

Domo connects to cloud data lakehouse platforms via pre-built connectors and data federation, querying data in place without replication. This matters when data lives across many systems (cloud apps, databases, warehouses, and on-prem sources) and the goal is one unified data layer for BI and AI.

On the pipeline side, Domo can automate ingestion with incremental and event-based patterns to keep lakehouse tables fresh without constant full reloads. DomoStats data lineage tracking helps teams see how data flows from source to destination across the lakehouse pipeline. Handy when a dashboard metric looks "off" and someone asks the classic question: where did this number come from?

Transformation is where many lakehouse projects either click or stall. Magic Transform (including Magic ETL) supports no-code and SQL-based approaches, whether the team prefers extract, transform, load (ETL) or extract, load, transform (ELT). And when it's useful to keep curated outputs in the lakehouse, Magic Transform can write back curated datasets into platforms like Databricks or Snowflake.

Governance controls in Domo complement catalog-enforced policies in the lakehouse, so access rules remain consistent from storage to dashboard. Row- and column-level permissions, audit trails, and encryption in transit help extend enterprise governance expectations into the analytics layer.

On the consumption side, Domo BI and AI Chat (also called DomoGPT in some experiences) help business teams explore lakehouse-backed datasets without writing SQL. And for teams that want model output to trigger action, Agent Catalyst can connect AI agents to governed datasets and documents, using RAG patterns to answer questions and kick off workflows based on what the data says.

To see how Domo queries governed lakehouse tables in place and routes insights into alerts, workflows, and embedded experiences, Get a demo.

Final thoughts

The lakehouse pattern continues to mature. Gartner published its first Market Guide for Data Lakehouse Platforms in September 2025, and open table formats are gaining adoption as AI workloads demand governed, unified data access. For teams running both reporting and ML on the same data, a lakehouse architecture reduces duplication, simplifies governance, and lowers storage costs without sacrificing the query performance business teams expect.

Compaction, partitioning, and multi-engine governance require attention that traditional warehouses abstract away. Evaluate your workload mix, governance requirements, and internal skill sets before committing.