Lakehouse architecture: how it unifies analytics and AI on a single platform

A lakehouse architecture unifies analytics and AI by sharing a governed data layer, transactional tabular formats, and specialized compute engines for BI, streaming, and machine learning. Its value lies not in “putting everything in a lake,” but in reducing copies, pipelines, and discrepancies, improving freshness, traceability, and total cost.

Taxonomic definitions

1. Lakehouse architecture

A lakehouse It is a data architecture pattern that combines the flexible storage capabilities of a data lake with features traditionally associated with a data warehouse, such as transactions, governance, quality, performance for SQL queries, and schema control.

Databricks defines the lakehouse precisely as a system that combines the advantages of data lakes and data warehouses to enable analytics, BI, and machine learning workloads to work on a common basis.

2. Open table format

It is the layer of metadata and transactions that organizes stored files, usually in columnar formats like Parquet, so that they can behave like reliable tables.

Technologies such as Delta Lake and Apache Iceberg They incorporate capabilities such as:

• ACID transactions.
• Evolution of schemes.
• Data versioning.
• Managing competition.
• Recovery of previous versions.
• Separation between storage and processing engines.

Delta Lake, for example, extends Parquet files through a transactional log that provides ACID operations and scalable metadata management.

3. Unified government of data and AI

It is the model through which data, models, metadata, permissions, lineage, and analytical assets are managed from common policies.

The critical point is that a lakehouse It is not really unified if storage, BI, and AI use different access rules, data versions, or catalogs. The platform may be technically centralized and remain fragmented from the government.

Comparative table

Lakehouse vs. data warehouse vs. data lake

Criterion	Traditional data warehouse	Traditional data lake	Modern Lakehouse
Structured data	High support	Yes	High support
Unstructured data	Limited or requires preparation	High	High
BI and SQL	Main fortress	Normally requires additional motors	Integrated
Machine Learning / AI	It may require export or integration	Suitable for data science	Designed to coexist with analytics
ACID transactions	Yes	Not necessarily	Yes, through formats like Delta or Iceberg
Scheme	Generally schema-on-write	Mainly schema-on-read	Both models according to the layer
Streaming	Additional integration	Possible	It can coexist with batch
Government	Maduro	It can be fragmented	Centralized catalog and government
Data copies	Common among DW, lake and ML	Frequent towards BI	Look for ways to minimize duplication
Open formats	It depends on the platform	Usually yes	Often Delta, Iceberg and Parquet
Analytics + AI on the same data	Not always	Partial	Architectural objective
Main risk	Stiffness and duplication	Data swamp	Poor governance and computing consumption

The boundary between categories is becoming increasingly fluid: modern data warehouses already incorporate semi-structured data and AI, while lakehouse platforms add warehouse capabilities. The relevant difference is no longer the name of the product, but How data is stored, governed, and reused.

Microsoft, for example, describes OneLake as a single repository for analytics and AI capable of storing Delta Parquet or Iceberg tables and allowing different engines to work on the same copy of the data.

Technical team

What really unifies a lakehouse architecture

A lakehouse architecture should not be evaluated by simply asking where the data will be stored.

The correct question is:

How many times must a data be copied, transformed, governed, and reconciled before it can be used by a dashboard, a predictive model, or an AI agent?

In fragmented architecture, it is common to find a flow similar to this:

ERP → Data Lake → ETL → Data Warehouse → Data Mart → File for Data Science → feature store → AI application.

Each movement introduces:

• Infrastructure.
• Processing.
• Additional pipelines.
• Security checks.
• Validations.
• Latency.
• Risk of working with different versions.
• Hours of engineering and support.

The lakehouse approach attempts to replace part of that chain with a common base upon which different engines consume governed assets.

Databricks points out that this pattern allows for the use of the same data for BI, data engineering, streaming, data science, and machine learning, reducing the need for isolated systems and redundant copies.

The key principle: separating storage from computing

A modern lakehouse architecture usually keeps the data in object storage and runs different engines on top of it depending on the required load.

This allows for:

• SQL should use optimized computing for queries.
• Engineering processes transformations.
• Streaming processes events.
• Machine Learning trains models.
• AI applications consult governed data.
• Each load scales independently.

It doesn't mean using the same cluster for everything.

It means sharing the data asset without forcing the sharing of the same processing engine.

Components of a lakehouse architecture prepared for AI

1. Data sources

The design should start by identifying where the data originates:

• ERP.
• CRM.
• Transactional systems.
• SQL and NoSQL databases.
• SaaS.
• Documents.
• Logs.
• IoT.
• Application events.
• Images, audio and video.
• External data.

An organization does not need to automatically move all these sources to the lakehouse.

First it must be determined:

what data produces analytical, operational or AI-based value.

2. Ingestion layer

Architecture must withstand various patterns:

• Batch.
• Streaming.
• Change Data Capture (CDC).
• APIs.
• Archives.
• Federated integration.
• Virtualization or shortcuts when moving the data does not add value.

This last point is important.

A lakehouse should not become a project of copying all the corporate data to another place.

Microsoft, for example, uses shortcuts and access mechanisms that allow data to be connected while avoiding certain movements and duplications.

3. Storage based on open formats

Storage alone does not constitute a lakehouse.

A transactional layer is needed to allow data to be managed as reliable tables.

Among the most relevant formats are:

Delta Lake

• ACID transactions.
• Schema enforcement.
• Evolution of schemes.
• Batch processing and streaming.
• Scalable metadata.

Apache Iceberg

• Schema evolution.
• Hidden partitioning.
• Partition evolution.
• Snapshots.
• Time travel.
• Rollback.
• Optimistic competition.

The importance for direction is not the format itself.

The benefit is that the same assets can be used by multiple tools without converting each platform into the owner of another copy of the data.

Interoperability around Iceberg is already present, for example, in platforms like Snowflake. Its documentation supports Iceberg tables stored in Parquet with ACID transactions, schema evolution, and snapshots.

Medallion Architecture: Bronze, Silver and Gold

One of the most commonly used patterns for structuring a lakehouse is to separate the data based on their degree of refinement.

Bronze: preserve evidence

It contains data close to its original form.

Its goal is to preserve:

• Historical.
• Traceability.
• Reprocessing.
• Auditing.
• Recovery from transformation errors.

It should not be the layer used directly by an AI corporate agent.

Silver: building trust

Here processes are carried out such as:

• Cleaning.
• Duplication.
• Standardization.
• Validation.
• Integration of different sources.
• Application of quality rules.

This is where the data begins to become a reusable business asset.

Gold: serving the business

It contains information prepared for specific cases:

• Executive KPIs.
• Forecast.
• Profitability.
• Customer segmentation.
• Risk.
• Operation.
• Features for ML.
• Authorized context for AI applications.

Databricks documents this pattern as a data progression. Bronze → Silver → Gold, By increasing quality and preparation as they progress through the different layers.

The layer that many companies forget: catalog and semantics

A technically correct lakehouse can fail if nobody understands what the data means.

Suppose there are five columns:

• Revenue
• Sales
• net sales
• invoice_value
• recognized_revenue

An AI agent can find them all.

The problem is determining which represents the revenues that the CFO recognizes as valid.

Therefore, an architecture prepared for AI also needs:

• Catalog.
• Data owners.
• Lineage.
• Classification.
• Business glossary.
• Rules of access.
• Quality.
• Semantic definitions.
• Identification of sensitive information.

Here is one of the differences between building data infrastructure and building Data Intelligence.

An AI model needs to find data.

An AI business system needs to understand what data can be used, what it means, who authorized it and how reliable it is.

How analytics and AI coexist on a lakehouse

The lakehouse should not create two parallel architectures: one for BI and another for AI.

The same Silver or Gold datasets can feed different consumers.

Analytics

You can use:

• SQL.
• Dashboards.
• Power BI.
• Financial reporting.
• KPIs.
• Forecasting.

Machine Learning

You can consume:

• Features.
• Historical series.
• Labeled data.
• Events.
• Operational information.

Generative AI and agents

You can use:

• Structured data.
• Documents.
• Metadata.
• APIs.
• Derived vector indices.
• Knowledge bases.

There is an important distinction:

The database vector should not become the new source of corporate truth.

Embeddings and vector indices are service layers for information retrieval. The governed source must remain in the data architecture.

This allows updating, versioning, auditing, and eventually rebuilding the indexes when documents, permissions, or embedding models change.

How to implement a lakehouse without migrating everything at once

Step 1. Build the economic and technical baseline

Before choosing a platform, document:

• How many repositories exist.
• How many copies of the same domain exist.
• How many pipelines maintain those copies.
• Annual storage cost.
• Cost of computing.
• Licensing.
• Hours of administration.
• Cost of integration.
• Egress.
• Quality-related incidents.
• Time required to deliver a new dataset.
• Time required to enable data for AI.

Without this baseline, it will be impossible to demonstrate ROI.

Step 2. Choose a business domain

Do not start migrating the entire enterprise data warehouse.

Select a domain where analytics and AI can truly share information.

Examples:

• Customer.
• Sales.
• Manufacturing.
• Inventory.
• Service.
• Finance.
• Supply chain.

A good candidate presents simultaneously:

• Several sources.
• Duplication.
• Analytical need.
• Need for AI.
• Identifiable economic pain.

Step 3. Design the data model and governance before the AI model

Definition:

• Data owner.
• Data steward.
• Classification.
• Accesses.
• Retention policy.
• SLA of update.
• Quality rules.
• Business definitions.
• Required lineage.

If these decisions are delayed, AI will simply automate the consumption of poorly governed data.

Step 4. Choose what to move and what to federate

Classify the assets into:

Migrate
when the operating or economic benefit justifies consolidating them.

Reply
when there is a specific need for performance, continuity, or isolation.

Federate
when the data must remain in its original system.

Delete
when duplicates or assets without consumers are discovered.

This analysis often generates value even before AI is implemented.

Step 5. Create the first data product

Do not measure success by terabytes migrated.

Measure it by a reusable asset.

For example:

Data product: client 360

Consumers:

• Commercial dashboard.
• Churn model.
• Segmentation.
• Forecast.
• Sales agent.

Five use cases consuming a governed product are more valuable than five projects building their own integrations.

Step 6. Simultaneously connect an analytical case and an AI case

Here the central hypothesis of the lakehouse is validated.

Example:

Analytical case: detect orders with a risk of delay.

AI Case: An agent who explains what orders are at risk, the causes, and the recommended actions.

Both should consume the same validated business information.

Step 7. Implement FinOps from the design phase

Cloud storage can be economical.

Mismanaged computing does not necessarily mean it will be so.

Control from the beginning:

• Consumption by workload.
• Costs for a domain.
• Idle jobs.
• Inefficient consultations.
• Unnecessary detention.
• Duplicate processing.
• Size and distribution of files.
• Development environments.
• Model training.
• Inference.

Replacing five silos with a cloud-based, unattended compute lakehouse does not solve the TCO. It only changes where the invoice appears.

How to measure the financial impact and ROI of the lakehouse

First build the current TCO

A practical way to calculate is:

Actual TCO =

Cost of Data Warehouse

• Data Lake
• Integration platforms
• ETL/ELT processing
• Duplicate storage
• Data transfer
• Licenses
• administration
• Support
• cost of data-related incidents.

Afterwards compare against:

TCO lakehouse =

Storage

• computation
• integration
• Catalogue/government
• operation
• observability
• Security
• FinOps.

It should not be assumed that a lakehouse will automatically be cheaper.

It must be demonstrated.

ROI Formula

An executive assessment can use:

ROI = [(avoided costs + recovered productivity + incremental value) – investment] / investment × 100

Costs avoided

They can include:

• Platforms removed.
• Pipelines removed.
• Less duplicate storage.
• Less maintenance.
• Lower data transfer.

Productivity

Size:

• Time to enable datasets.
• Hours of engineering per pipeline.
• Time spent reconciling information.
• Time to prepare data for models.

Incremental value

It can come from:

• More accurate forecast.
• Lower inventory.
• Reduction of fraud.
• Higher conversion rate.
• Predictive maintenance.
• Automation through agents.

For a CFO, this is the right conversation to have.

No:

“We are going to implement a lakehouse architecture.”

Sino:

“We will reduce the cost and latency of turning business data into decisions and automation.”

How the lakehouse connects to EBITDA

The potential impact can be classified in four ways:

Lever	Economic impact
Technological consolidation	Lower technological OPEX
Less repetitive engineering	Productivity and freed capacity
Faster decisions	Potential improvement in margin or revenue
AI based on reliable data	Automation and productivity
Less information errors	Lower operational exposure
Infrastructure withdrawal	Reduction of TCO

Architecture alone does not generate EBITDA.

Generates the Technical capacity to capture those benefits.

The measurement must then be linked to operational results.

Risks that can turn a lakehouse into another silo

1. Convert the lakehouse into a data repository

Storing all data without ownership, cataloging, or quality rules produces a data swamp with the latest technology.

2. Allow AI to consume Bronze directly

Raw data can contain:

• Duplicate information.
• Incomplete values.
• Sensitive data.
• Incorrect definitions.
• Information without authorization for AI.

3. Confusing open format with absence of lock-in

Delta Lake and Iceberg improve interoperability.

That doesn't mean that pipelines, notebooks, security services, catalogs, and proprietary APIs are automatically portable.

The risk of dependence must be evaluated in all the architecture, Not only in the storage format.

4. Migrate everything before demonstrating value

The type programs big bang They increase initial investment, risk, and time before showing results.

The recommended strategy is:

domain → data product → analytical case → AI case → measurement → expansion.

5. Do not separate environments and workloads

Experimental data science should not compete for resources with month-end financial reporting.

Unification must happen in data and government.

Not necessarily in terms of numbers.

When it is not advisable to implement a lakehouse architecture

A lakehouse is not a universal requirement.

It may not be justified when:

• There is a stable data warehouse that covers virtually all needs.
• The volume and variety of data are reduced.
• There are no significant AI, ML, or streaming workloads.
• There are few sources.
• There is no significant duplication.
• The cost of migration exceeds the expected benefit.

It is also incorrect to use a lakehouse to replace transactional systems.

The ERP, CRM or core operational system continues to be the system responsible for recording certain processes.

The lakehouse should become a Governed source for analytics and intelligence, Not in automatic replacement of operational applications.

Predictive conclusion

Over the next 12 to 24 months, the discussion of architecture will likely shift from “data warehouse vs. data lake” towards What layer of data can be safely shared by humans, analytics, models, and AI agents?.

The technological evidence already points in that direction. Databricks uses Delta and supports interoperability with Iceberg; Microsoft OneLake works with Delta Parquet and Iceberg; Snowflake supports Iceberg tables; Apache Iceberg continues to develop as an open specification.

The strategic asset will no longer be simply where the data is stored. It will be how easily it can be discovered, governed, reused, and turned into an automated decision or action.

For Scanda, that is the central point: applied artificial intelligence should not start by selecting a model. It should start by identifying value, preparing the data, and building an architecture that allows for controlled scaling of intelligence. MaIA by Scanda positions itself precisely as a Data Intelligence initiative from Grupo Scanda, with an agnostic platform approach focused on preparing data, deploying AI, and measuring results.

CTA final of MaIA

Your AI models should not discover the problems in your production data

Before investing in new agents, copilots, or models, identify what data exists, where it is located, which ones are reliable, and what architecture you need to use it safely.

With MaIA by Scanda, we evaluate your level of preparedness, identify the use cases with the greatest impact, and design a data and AI architecture aligned with the business, without forcing you into a specific platform.

Request an AI Value Discovery with Scanda and turn your data into a foundation ready for analytics, automation, and measurable artificial intelligence.

FAQ

1. Does implementing a lakehouse always reduce costs?

No. It can reduce storage duplication, data movement, platforms, and maintenance, but the savings depend on the current architecture. A lakehouse with oversized compute or without FinOps can even raise the cost. Before investing, a TCO baseline must be built and compared against the target scenario.

2. Do we need to replace our data warehouse to adopt a lakehouse?

No. A lakehouse strategy can coexist with existing warehouses and systems through integration, federation, or non-copy access mechanisms. Migration should prioritize domains where duplication, latency, or the need for AI justify the change, avoiding mass replacement programs without a financial case.

3. Does a lakehouse mean that our data is already ready for AI?

No. The lakehouse provides the architectural foundation, but preparing for AI requires quality, cataloging, lineage, security, semantics, ownership, and explicit usage rules. An agent connected to centralized but poorly defined data can generate responses faster, but not necessarily better.