Data Lakehouse: Architecture, Benefits and Enterprise Use

A data lakehouse is a data architecture that combines the flexible, cost-efficient storage of a data lake with the management and query capabilities of a data warehouse. Data is stored in open file formats on low-cost object storage, while a metadata layer provides capabilities such as transaction consistency, schema management, and SQL queries - without requiring the data to be copied into a separate system.

 

Why Data Lakes and Data Warehouses Alone Are No Longer Enough

In many organizations, both systems have evolved side by side over time: a data warehouse for reporting and a data lake for data that does not fit into the warehouse. The two environments are operated and maintained separately, and in many cases they store overlapping copies of the same data. This increases the effort required for operations, licensing, and coordination between the two architectures.

Data Lakehouse architecture

  • The data warehouse: reliable, but limited

    A data warehouse stores structured data according to a predefined schema. This makes the data reliable, fast to query, and well suited to reporting and analytics. The trade-off is that each new data source must be modeled in advance, while unstructured data such as images, logs, or free text does not fit naturally into the architecture. Storage is also comparatively expensive, and a traditional data warehouse is rarely the ideal environment for machine learning workloads.

  • The data lake: flexible, but difficult to manage

    A data lake can store structured, semi-structured, and unstructured data at relatively low storage cost. That flexibility is also its main challenge: without schema management, transaction consistency, and reliable metadata, a data lake can quickly become difficult to govern and navigate. A data lake without effective governance risks becoming an expensive archive in which data is hard to find, understand, and reuse.

  • The typical dual architecture

    In practice, this often results in the same architecture: raw data is stored in a data lake, part of it is prepared and copied into a data warehouse, reports access the warehouse, and data science workloads use the lake. Two systems, two copies of the same data, two governance models - and recurring questions about which figure is the correct one.

    This is exactly where the data lakehouse model comes in: one copy of the data, one governance model, both types of workloads.

More about data architectures

Data Lakehouse, Data Warehouse, and Data Lake Compared

  •  Data WarehouseData LakeData Lakehouse
    Data typesStructuredAll data typesAll data types
    SchemaDefined when data is writtenApplied when data is readDefined when data is written, but can be changed flexibly
    Storage costsHighLowLow
    Transactional consistencyYesNoYes, through open table formats
    SQL queriesNativeLimitedNative
    Machine learningDifficultWell suitedWell suited
    GovernanceMatureLimitedManaged through the metadata layer
    Data copiesData usually needs to be copied from the data lake—No second copy required
    Typical limitationInflexible and comparatively expensiveGovernance and data discoverabilityNewer architectural approach with a rapidly evolving tool ecosystem

How a Data Lakehouse Works Technically

Open table formats: Delta Lake and Apache Iceberg

Open table formats are a core component of a data lakehouse. They add a metadata layer on top of standard Parquet files in object storage and provide capabilities that a traditional data lake lacks, including transactional consistency, versioning, and schema management.

Two formats are particularly important. Delta Lake originated in the Databricks ecosystem and is also used by Microsoft Fabric for data stored in OneLake. Apache Iceberg was originally developed at Netflix and is now maintained as an Apache project; it is widely used in the Snowflake and AWS ecosystems.

In practice, the distinction between the two formats is becoming less rigid. Major data platforms increasingly support both for

The Medallion Architecture: Bronze, Silver, and Gold

Within a data lakehouse, a layered model known as the Medallion Architecture has become widely established. It describes how data is progressively refined from raw source data into analysis-ready data and business metrics.

Medallion Architecture with Bronze, Silver, and Gold layers
  • LayerContentPurpose
    BronzeRaw data, stored as receivedTraceability and the ability to reprocess data at any time
    SilverCleaned, deduplicated, standardized, and joinedReliable foundation for downstream analysis and processing
    GoldBusiness-ready, aggregated, and KPI-oriented dataDirect use in reports and dashboards

The value of the model lies less in the technology itself than in the clarity it provides: each layer has a defined purpose, a defined level of data quality, and defined access rights. If a figure is questioned, it can be traced back to the original source data.

One limitation from project experience: Three layers are a convention, not a rule. Smaller projects may work well with two layers, while complex data environments sometimes require an additional intermediate layer. Applying the model too rigidly can create unnecessary complexity without adding practical value.

Data Lakehouse in Practice: Microsoft Fabric and Databricks

A data lakehouse is an architectural pattern, not a product. In practice, it is implemented on a data platform - and the choice often comes down to two main options.

 

  • Microsoft Fabric with OneLake

    Data Lakehouse in Microsoft Fabric with OneLake

    In Microsoft Fabric, the lakehouse architecture is built into the platform. OneLake is the unified data lake used by Fabric workloads and is built on Azure Data Lake Storage. Each Fabric tenant includes a single logical OneLake for the organization. Fabric primarily stores analytical tables in the open Delta Lake format based on Parquet. OneLake shortcuts can provide access to data in other storage locations without requiring the data to be copied.

    Microsoft Fabric is particularly relevant in environments where Power BI is already in use and platform administration should remain limited. Fabric is provided as a SaaS platform, so organizations do not need to manage their own compute clusters. Data access, permissions, and governance can be managed across Fabric and OneLake.

     

  • Lakehouse with Databricks

    Data Lakehouse with Databricks

    Databricks played a major role in establishing the lakehouse concept and developed Delta Lake, the open table format used by many lakehouse architectures today - including Microsoft Fabric. 

    The Bronze, Silver, and Gold layering model known as the Medallion Architecture also originated in the Databricks ecosystem and has been used in production environments for many years.

    For very large data volumes, complex data engineering, and machine learning workloads, Databricks often provides greater flexibility and control. The trade-off is a higher entry barrier: teams typically need more platform expertise, but gain more control over data processing, compute resources, and costs.

    More about D

How to choose

In practice, the decision is rarely determined by technical details alone. Three questions usually point to the right choice:

  • Where is your data today, and which platforms does your team already use? An organization that already works extensively with Microsoft 365, Microsoft Entra ID, and Azure will generally have a shorter path to Microsoft Fabric.
  • How complex are your data engineering requirements? For complex data processing pipelines and production machine learning workloads, Databricks provides more control.
  • Which skills are available in-house? The most suitable platform is one that your team can operate and develop independently.

Informatec is a Microsoft Solutions Partner for Data & AI and an official Databricks Consulting Partner. For that reason, we do not recommend one platform over the other before assessing your existing environment and

When a Data Lakehouse Makes Sense - and When It Doesn’t

  • A data lakehouse makes sense when:

    • you currently operate a data lake and a data warehouse in parallel and store the same data multiple times
    • unstructured or semi-structured data needs to be used for analytics
    • analytics and machine learning should work on the same underlying data
    • governance, data lineage, and traceability need to be applied consistently across the data platform
    • data warehouse storage costs have become a significant consideration

  • A data lakehouse is less suitable when:

    • your data volumes and requirements are adequately covered by a well-modeled database combined with a BI tool
    • you only process structured data from a small number of stable source systems
    • there is no current or foreseeable need for machine learning or real-time data processing
    • no one on the team can develop and maintain the architecture over the medium term

How a Data Lakehouse Project Works

A phased approach based on the principle start small, grow big has proven effective: first assess the existing data landscape, then define a target architecture, and implement a single business case as an MVP before expanding further. Two topics should be addressed from the outset: identifying personally identifiable and sensitive data (PII), and defining the required data load frequency for each source system. Both influence the design of the lakehouse layers and are difficult to retrofit later without significant effort.

Microsoft Fabric consulting

 

 

From Practice: Benchmarking Platform in Healthcare

For Keller Unternehmensberatung AG, Informatec rebuilt the HEBES benchmarking platform on Microsoft Fabric. Data from SOMED and KORE ARTISET is combined in a shared, anonymized data model; analysis is performed in Power BI, access permissions are managed through Microsoft Entra ID, and data storage remains in Switzerland. New data is available within four hours of upload.

Read the full success story

Microsoft Fabric Success Story Keller Unternehmensberatung AG

Frequently Asked Questions About Data Lakehouses

A data lakehouse is a data architecture that combines the cost-efficient storage of a data lake with the management and query capabilities of a data warehouse. Data is stored in open formats on object storage and managed through a metadata layer that enables transactional consistency, schema management, and SQL queries - without requiring a second copy of the data.

A data warehouse stores structured data according to a predefined schema. A data lakehouse can also store semi-structured and unstructured data, typically at lower cost on object storage, while still supporting SQL queries and transactional consistency. For standard reporting on a small number of stable, structured data sources, a data warehouse often remains the simpler solution.

A data lake stores data in a wide range of formats but does not inherently provide schema management or transactional consistency. A data lakehouse adds these capabilities through a metadata layer based on open table formats such as Delta Lake or Apache Iceberg. In this way, a lakehouse combines the flexible storage of a data lake with data management and query capabilities typically associated with a data warehouse.

The Medallion Architecture is a layered data model used in a data lakehouse. It typically consists of three layers: Bronze contains unchanged raw data, Silver contains cleaned and standardized data, and Gold contains business-ready metrics for reports and dashboards. Each layer has its own data quality level and access rules, making it possible to trace figures back to the original source data.

Delta Lake is an open table format that adds a metadata layer on top of Parquet files, providing transactional consistency, versioning, and schema management. It originated in the Databricks ecosystem and is also the table format used by Microsoft Fabric for data stored in OneLake.

OneLake is the storage layer of Microsoft Fabric and therefore the foundation on which a data lakehouse can be built - it is not the lakehouse itself. OneLake is based on Azure Data Lake Storage Gen2 and stores data in the open Delta-Parquet format. The lakehouse is created by combining OneLake with Microsoft Fabric workloads for data processing, querying, and analytics.

No. A data lakehouse is an architectural pattern and is not tied to a specific vendor. Databricks played a major role in establishing the concept, but Microsoft Fabric, Snowflake, and other platforms also implement lakehouse architectures. The most suitable platform depends on the existing system landscape, data engineering requirements, and the skills available within the team.

Data lakehouse projects are best supported by consulting firms with proven experience in data architecture and data integration, as well as recognized partner status with the relevant platform providers. Informatec supports data lakehouse projects in Switzerland, Germany, and Austria as a Microsoft Solutions Partner for Data & AI and an official Databricks Consulting Partner, allowing projects to be assessed without being tied to a single technology platform.

Updated: 14.09.2026