Data Lakehouse vs Data Warehouse: How to Choose in 2026

Illustration of a data warehouse, a data lakehouse and a data lake side by side, linked by data flows

Data lakehouse vs data warehouse comes down to one question: do you need trusted reports, flexible raw data, or both? A data warehouse stores cleaned, structured data so every report shows the same numbers. A data lake stores raw data of any kind, cheaply, for exploration and machine learning. A data lakehouse keeps data in open files on cheap storage, like a lake, and adds the rules, safe updates and fast queries of a warehouse. Pick a warehouse for reliable reporting. Pick a lakehouse when reporting and AI must share the same data and you have the engineers to run it. Many teams use both.

Who this is for: a business owner, analyst or manager who hears these words in meetings and must make, or sign off, a decision. It also suits a tech-curious reader or a home-lab reader, who wants to know how data platforms work at company scale. Who it is not for: an engineer who wants a benchmark shoot-out. This is a decision guide, not a vendor test.

Data lakehouse vs data warehouse vs data lake at a glance

Think of three ways to store a shop's stock. A data warehouse is like the shop floor: every item is cleaned, labeled and on the right shelf, so anyone finds it fast. A data lake is like a storage unit: everything goes in, in its original boxes, and you sort it when you need it. A data lakehouse is that storage unit with a stock list, a label on every box and a lock on every shelf.

Dimension	Data warehouse	Data lake	Data lakehouse
Main data	Structured, cleaned data	Raw data of every kind: tables, logs, JSON, images, video	All data types
Schema approach	Schema-on-write	Schema-on-read	Schema enforced on tables, raw files kept as they are
Best for	Business reporting, finance, operations dashboards	Data science, machine learning, logs, experiments	Reporting and machine learning on one copy of the data
Main strength	Fast, consistent answers to reporting questions	Cheap, flexible storage at large scale	Flexibility with governance and good query speed
Main risk	Rigid, and every new source needs modeling work	Becomes a "data swamp" nobody trusts	More moving parts, and it needs a skilled platform team

Schema-on-write vs schema-on-read

Two terms in that table need a plain definition. Schema-on-write means you decide the structure (columns and types) before data goes in, and the system rejects data that does not fit. Schema-on-read means you store data as it arrives and apply a structure only when you read it. The first gives you trust. The second gives you flexibility.

Start with the business question, not the tool

Most teams start with "Snowflake or Databricks?" That is the wrong first question. Ask a better one: do you need reliable reporting, flexible exploration, or both?

Reliable reporting means the finance total, the sales dashboard and the board pack agree, every day. That is warehouse territory.
Flexible exploration means keeping raw data you have not modeled yet: clickstreams, sensor readings, support tickets, documents. That is lake territory.
Both, on the same data is the reason lakehouses exist.

Your answer leads to one of four choices: a warehouse, a lake, a lakehouse, or a hybrid of a lake and a warehouse. The rest of this guide gives you what you need to pick one.

What is a data warehouse?

A data warehouse is a central database that holds cleaned, business-ready data from many sources, organized for analysis. Bill Inmon, often called the father of the data warehouse, described it as subject-oriented, integrated, time-variant and non-volatile. In plain words: it is organized by business topic. It joins up data from different systems. It keeps history, and it does not change data once loaded.

A warehouse is not the database behind your app. An app database handles many small writes, such as "add this order". A warehouse handles fewer, bigger questions, such as "revenue by region by month for three years". Engineers call the first kind of work OLTP (online transaction processing). They call the second OLAP (online analytical processing).

How data gets in: ETL vs ELT

Data reaches a warehouse through a pipeline. There are two common patterns.

ETL (extract, transform, load): you pull data from the source, clean and reshape it on a separate server, then load the finished result. This was the norm when warehouse storage and compute were expensive.
ELT (extract, load, transform): you load raw data into the warehouse first, then transform it there with SQL. Cloud warehouses made this the common choice, because their compute scales up when you need it.

ELT keeps the raw copy, so you can rebuild a report when a business rule changes. ETL keeps less data in the warehouse, which can help when data is sensitive. Most teams use a mix. If you are starting today on a cloud warehouse, ELT is the usual default.

Data warehouse design: star and snowflake schemas

Most warehouses use dimensional modeling, a method made popular by Ralph Kimball. It splits data into two kinds of table.

Fact tables hold events and measures: an order, a payment, an ad click, with amounts and counts.
Dimension tables hold the context you filter and group by: customer, product, date, store, campaign.

A star schema puts one fact table in the middle with the dimension tables around it, like the points of a star. It is simple for people and fast for business intelligence (BI) tools, the dashboard software people use. A snowflake schema splits dimensions into smaller tables, for example product, then product category, then department. That saves some space and removes duplication, but it adds joins and makes queries harder to write. (This is a design pattern, not the company Snowflake.) Most teams start with a star.

SQL, BI tools and the semantic layer

People ask a warehouse questions in SQL, the standard language for asking a database questions. They usually do it through a BI tool such as Power BI, Tableau or Looker. A semantic layer sits between the tables and the tools. It defines each metric once, for example "active customer" or "net revenue", so every dashboard uses the same rule. Without one, two teams can report two different revenue figures from the same data.

Vendors build warehouses for concurrency: many people running queries at the same time. For example, a Monday morning with 200 people opening dashboards is a normal warehouse day.

Who uses it, and data warehouse examples

Typical users are analysts, finance teams, operations managers and executives. Typical workloads:

Revenue dashboards: daily sales by product, region and channel.
Cohort analysis: how customers who joined in March behave over the next twelve months.
Inventory reporting: stock levels, turnover and reorder points across stores.
Customer lifetime value: revenue per customer over time, joined with marketing cost.
Marketing performance: ad spend from several platforms side by side with leads and sales.

A warehouse does not have to be big or expensive. One small marketing team runs four daily data feeds on managed open-source databases for about US$45 to US$60 a month. That covers the foundation only: databases, scheduled jobs and private access. Staff time and any tools on top cost extra. A full case study of that build is coming to this site later this year.

What is a data lake?

A data lake is a large store of raw data in its original format. It usually sits on cheap object storage, such as Amazon S3, Azure Data Lake Storage or Google Cloud Storage. Object storage keeps files as "objects" with a name and some metadata, rather than as rows in a database. It is cheap per gigabyte and it scales almost without limit. For how object storage compares with SAN and NAS, see storage virtualization explained.

What goes in a lake

Anything can go in: CSV exports, JSON from APIs, application logs, clickstream events, images, audio, video and PDFs. For analytics, teams usually convert data to Parquet, a column-based file format that compresses well and lets a query read only the columns it needs. Avro is a row-based format often used for streaming data.

Zones: raw, curated and in between

A well-run lake has zones. A raw zone keeps data exactly as it arrived, so you can always go back. A cleansed or staging zone holds data with fixed types and obvious errors removed. A curated zone holds data ready for a specific use. Data arrives in batches (for example, a file every night) or as a stream (events every second, often through a tool such as Apache Kafka).

Who uses a lake

Data engineers build the pipelines. Data scientists use the raw and curated data to explore ideas and to train machine learning models. Some teams add a feature store. It is a catalog of ready-made model inputs, such as "orders in the last 30 days per customer". Every model then uses the same definition.

The data swamp problem

A lake with no rules turns into a swamp. The signs are easy to spot:

Nobody knows who owns a dataset, or if it is still updated.
Five copies of "customers" exist, each slightly different.
Files have no documentation, so people guess what the columns mean.
Quality is unknown, so people stop trusting the data and go back to spreadsheets.

Plain object storage also has no transactions. If a job fails halfway through writing, readers can see half-written data. Two jobs writing at once can corrupt a table. Engineers built lakehouses to close these gaps.

Data lake vs data warehouse: the key difference

A warehouse holds data that is already cleaned and shaped for reports. A lake holds data as it arrived, and you shape it when you need it. The warehouse gives you trust. The lake gives you range and low storage cost.

What is a data lakehouse?

A data lakehouse stores data in open file formats on cheap object storage, like a lake. It then adds a table layer that gives you warehouse features: transactions, schema rules, versioning and fast SQL. Databricks made the term popular. It set out the idea in a 2021 research paper, "Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics". It is not just "a lake plus a warehouse" side by side. It is one copy of the data that both kinds of work can use.

Open table formats: the core of a lakehouse

The key part is an open table format. It is a set of metadata files that sits next to your Parquet files and turns a folder of files into a table you can query and update safely. Three formats lead:

Apache Iceberg, started at Netflix, now an Apache project with wide support across engines and clouds.
Delta Lake, started at Databricks, now a Linux Foundation project.
Apache Hudi, started at Uber, strong at frequent updates and inserts.

Because the formats are open, many query engines (the software that runs your questions) can read the same table. Spark, Trino, Snowflake, BigQuery, DuckDB and others support one or more formats, to different degrees. Check each engine's docs for what it can read and write.

What a table format adds

ACID transactions: a write either finishes completely or not at all, and readers never see a half-finished write. ACID stands for atomicity, consistency, isolation and durability.
Time travel: you can query the table as it was yesterday or at a past version, which helps with audits and with fixing mistakes.
Schema enforcement and evolution: the table rejects bad data, and you can add columns, and in most formats rename them, without rewriting the whole table.
Versioning: every change creates a new snapshot, so you can see what changed and when.

Medallion architecture: bronze, silver and gold

Lakehouses often organize data in three layers, a pattern called the medallion architecture. Databricks documents it, but you can use it on any platform.

Bronze: raw data as it arrived, kept for history and reprocessing.
Silver: cleaned, deduplicated and joined data, with fixed types.
Gold: business-ready tables for reports, dashboards and models, often in a star schema.

Lake zones (raw, cleansed, curated) are the same idea under different names. Notice that gold looks a lot like a warehouse. A lakehouse does not remove data modeling. It moves the warehouse onto open storage.

Catalogs and governance

A lakehouse needs a catalog: a central list of every table, where it lives, who owns it and who may read it. Catalogs also track lineage (which tables feed which) and enforce access rules. Examples include Unity Catalog, Apache Polaris and AWS Glue Data Catalog.

The honest trade-off

A lakehouse is not automatically cheaper or simpler. You trade a single managed product for a stack of parts: storage, a table format, a catalog, one or more engines, and the jobs that keep tables healthy. That works well with a strong platform team. Without one, it can fail in the same way a lake does, only more expensively.

Data warehouse architecture: how data flows on any platform

Whatever you choose, the flow is similar. Each step is explained below.

Sources (apps, ads, CRM, files)
        |
   Ingestion (batch, CDC, streams)
        |
 Storage (warehouse / lake / lakehouse)
        |
  Transformation (SQL, dbt, Spark)
        |
 Governance (catalog, tests, access)
        |
 Serving (BI, ML, apps, reverse ETL)

Ingestion

Data comes in four common ways:

Batch: a nightly export or file drop.
API: a scheduled job that calls a service, such as an ad platform.
Event streams: clicks and app events in real time.
CDC (change data capture): it copies only the inserts, updates and deletes from a source database, most often by reading the database's change log. CDC keeps a warehouse close to live without heavy full reloads.

Transformation

Transformation turns raw data into useful tables. SQL does most of this work. dbt is a popular tool that lets you write each transformation as a SQL file, test it and keep it in version control. Apache Spark handles large data and non-SQL work in Python or Scala.

Modeling choices

Kimball dimensional models (star schemas): the default for BI.
Data Vault, created by Dan Linstedt: it splits data into hubs (business keys), links (relationships) and satellites (history and details). It suits large, fast-changing enterprises that need full audit history, at the cost of more tables.
Wide tables: one big flat table per use. Easy for BI and for columnar engines, but hard to keep consistent across many teams.
Semantic models: the metric layer on top, so the business sees "revenue" and not five joins.

Orchestration

An orchestrator runs every job in the right order, retries failures and alerts someone when a job breaks. Common choices are Apache Airflow, Dagster and Prefect, plus the schedulers built into each cloud platform. A small team can start with simple scheduled jobs, as long as every job reports success or failure. Silence should count as failure.

Serving

Data leaves the platform to:

BI dashboards and reports.
Reverse ETL: pushing warehouse data back into tools such as a CRM or an ad platform.
APIs that other systems call.
Analytics embedded in your own product.
Machine learning pipelines.

Data warehouse cost vs lakehouse cost: what you pay for

"Lakes are cheaper" is half true. Raw storage on object storage is cheap. But storage is rarely the biggest line on the bill.

Cost driver	Warehouse	Lake or lakehouse
Storage per terabyte	Often close to object storage prices, though rates depend on billing model and region	Lowest list price, and you choose the storage tier
Compute	Pay per use; easy to start, easy to overspend	Clusters or serverless SQL; you tune it, and you pay for idle clusters
Engineering time	Modeling every new source	Building and running the platform itself, plus the same modeling
Data duplication and egress	Copies from the lake into the warehouse	One copy if engines share tables; egress fees when data crosses clouds or regions
BI concurrency	Built for it, and predictable	Possible, and it needs tuning and caching
Operations	Mostly handled by the vendor	Compaction, catalog, cluster sizing and upgrades

Storage

Object storage is the cheap base layer. Cloud warehouses also store data cheaply. As of October 2026 (a GiB is about a gigabyte, and a TiB is about a terabyte):

Amazon S3 Standard in US East lists US$0.023 per GB per month for the first 50 TB, roughly US$23 to US$24 per terabyte. Colder tiers cost less to store and more to retrieve.
BigQuery lists active logical storage at a similar level per GiB. Tables or partitions not modified for 90 days cost about half that. The first 10 GiB each month is free.
Snowflake bills storage at a flat rate per terabyte of compressed data.

Prices vary by region and change. Check the vendor pages before you plan.

In short: at small and medium scale, the storage line is rarely what makes one option cheaper than another. Retention is what grows it. Keeping every raw event forever "just in case" is how storage bills creep up. Set a retention rule for each zone.

Compute

Compute (the processing power that runs your queries) is where the bill grows. Each platform charges for it differently, as of October 2026:

Snowflake bills compute in credits, per second, with a 60-second minimum each time a warehouse starts or resumes.
BigQuery on-demand pricing charges by data scanned, listed at US$6.25 per TiB with the first 1 TiB each month free. Capacity pricing (reserved slots) is the alternative.
Databricks bills in DBUs (Databricks Units), a measure of processing power, per second. On classic compute you also pay the cloud provider for the servers. Serverless DBU prices include the servers.
Self-run Spark or Trino clusters cost whatever the servers cost while they run, including idle time.

Two habits cut compute cost on any platform. Auto-suspend idle compute. And stop dashboards from scanning whole tables: filter by date, split big tables by date (partitions) and use summary tables.

Engineering, duplication and operations

People cost more than storage. Every new source needs a pipeline, tests and a model, on any platform. A lakehouse adds platform work on top: choosing and upgrading engines, running the catalog, compacting small files and sizing clusters. Keeping a lake and a warehouse side by side adds copies of the same data and the pipelines that keep them in sync. Moving data between clouds or regions can add egress (data transfer) fees.

The cost of poor governance

The hidden cost is rework. When nobody owns a metric, three teams build three versions of it. When quality is unknown, analysts spend their week checking numbers instead of using them. When a board report is wrong, the cost is trust, and trust takes months to rebuild.

Performance and scalability

Warehouses usually win for many people running SQL dashboards at once. Lakes and lakehouses are stronger for large scans over raw data and for machine learning.

Query speed and concurrency: warehouses tune storage, caching and query planning together, because one vendor controls all of it. A lakehouse engine must work with open files that other engines also write.
Partitioning and clustering: both split tables by a column such as date, so a query for last week reads only last week. Pick the column people filter on most.
Indexes, materialized views and caching: a materialized view stores the result of a heavy query, so dashboards read the answer instead of recalculating it. Caching keeps hot data in memory.
The small-files problem: streaming and frequent small writes create thousands of tiny files. Each file adds overhead, so queries slow down. Lakehouses fix this with compaction jobs that merge small files into large ones, such as OPTIMIZE in Delta Lake or rewrite_data_files in Iceberg. Someone has to schedule them, or turn on a managed service that runs them automatically.
Batch vs streaming: nightly batches are simple and cheap. Streaming gives fresh data in seconds or minutes, but it costs more to build and run. Ask how fresh each report needs to be. Most finance reports are fine with yesterday.
Machine learning at scale: training reads large amounts of data at once. Engines such as Spark read lake files directly, in parallel, without moving them into a warehouse first.
Workload isolation: give analysts and data scientists separate compute, so a big training job does not slow down the morning dashboards.

Data governance and quality

Governance is the set of rules and roles that make data trustworthy. It decides who owns what, what each number means, and who may see it. It matters more than the platform choice.

Catalog and business glossary: a searchable list of every dataset, plus plain definitions of business terms.
Ownership and stewardship: every important dataset has a named owner, and a steward who looks after its quality.
Lineage and impact analysis: lineage shows which tables feed a report. Before you change a table, impact analysis shows what will break.
Audit trails: a record of who read or changed what, and when.
Access control: row-level security (a regional manager sees only their region), column-level security (only HR sees salary) and masking (support staff see the last four digits of a phone number).
Data contracts: a written agreement between the team that produces data and the teams that use it, covering columns, types and how the producer announces changes.
Quality checks: freshness (did today's data arrive?), completeness (are rows missing?), anomaly detection (for example, did spend jump 400 percent overnight?) and reconciliation (does the warehouse total match the source system?).

Warehouses have traditionally offered stronger built-in consistency and access control. Lakehouses bring those controls to open storage through the table format and the catalog. Either way, a tool only enforces rules that people have agreed. Buying a platform does not give you governance.

Security and compliance

Buyers and auditors ask about security directly, so treat it as its own checklist.

Encryption: at rest (on disk) and in transit (over the network). As of October 2026, the major clouds encrypt stored data by default. Encryption in transit is not always enforced: for example, Amazon S3 still accepts plain HTTP unless a bucket policy blocks it. Enforce HTTPS, and check who manages the keys.
Identity and access management: single sign-on, multi-factor authentication, and a separate least-privilege login for each pipeline.
Network controls: private connectivity so data does not cross the public internet, and no database port open to the world.
Data residency: where the data physically lives. Some contracts and laws require a specific region.
Retention and deletion: how long you keep data, and how you delete a person's data on request.
Vendor risk: certifications such as SOC 2 and ISO 27001, audit reports, and what happens to your data if you leave.

Deletion in a lakehouse needs extra care

Privacy laws give people rights over their data. Under GDPR Article 17, people in the EU and EEA can ask you to erase their personal data, with some exceptions. California's CCPA gives California residents a similar right to request deletion from businesses it covers. HIPAA, the US health privacy law, protects health records but works differently: it gives patients a right to amend records, not a general right to delete. Get legal advice for your own case.

The catch is in how deletes work. A DELETE in Delta Lake or Iceberg often does not remove the data from storage. To erase data physically, you need two steps:

Rewrite the affected files. Some tables rewrite files without the deleted rows. Others only mark rows as deleted (with deletion vectors or delete files), and the rows stay inside the current files. To purge them, run REORG TABLE ... APPLY (PURGE) in Delta Lake, or a compaction such as rewrite_data_files in Iceberg.
Delete the old files. The old versions stay so time travel still works. A cleanup job removes them: VACUUM in Delta Lake (default retention 7 days) or snapshot expiry in Iceberg (the Spark procedure defaults to snapshots older than 5 days).

A deletion request is complete only after both steps run, and after any backups that hold the data expire. Write that into your deletion process, and check your platform's docs, as of October 2026.

AI, machine learning and real-time analytics

This is where the three options differ most. Lakes and lakehouses are usually better placed for machine learning and unstructured data. Warehouses remain strong for governed, structured reporting.

Feature engineering: building model inputs from raw history. Lakehouses do this on the same tables the business reports from, so the model and the dashboard agree.
Training on lake data: frameworks read Parquet and table formats directly, without an export step.
Unstructured data, embeddings and RAG: documents, images and support tickets usually sit in a lake. An embedding is a list of numbers that captures the meaning of a piece of text, so a system can find similar content. RAG (retrieval-augmented generation) uses those embeddings to give an AI model the right documents before it answers. Many warehouses now also store vectors and call AI models from SQL, so check what your current platform already does.
Real-time analytics: streaming ingestion feeds operational dashboards, such as live orders or fraud alerts. Both warehouses and lakehouses support streaming today, with different cost and latency trade-offs.
MLOps (the routine work of running models in production): versioned training data (time travel helps), reproducible experiments, model monitoring and model governance.

A warehouse can still serve AI work. Many teams train models on curated warehouse tables. The lakehouse wins when the inputs are large, raw or unstructured.

Data warehouse management and operations

Building the platform is the start. Running it is the job. Data warehouse management, or lakehouse management, covers six jobs.

Deployment model

Fully managed (SaaS): the vendor runs everything. Least effort, least control.
Self-managed: you run open-source engines on your own servers or cloud accounts. Most control, most work. The same trade-off applies to a home server setup.
Hybrid: managed compute over storage in your own cloud account. This is common for lakehouses.

Capacity and workload management

Size compute for the busiest hour, not the average. Separate workloads (BI, pipelines, data science) so one cannot starve another. Set auto-suspend on idle compute, and set spending limits and alerts on every account from day one.

Monitoring

Watch four things: slow and expensive queries, pipeline failures, cost anomalies and data freshness. A dashboard that is quietly two days out of date is worse than one that shows an error.

DevOps for data

Treat data code like application code. Keep SQL and models in version control. Use separate development, test and production environments. Run automated tests on every change, such as row counts, unique keys and no unexpected nulls. CI/CD (continuous integration and delivery) runs them for you. A broken model then never reaches the CEO's dashboard.

Backups, disaster recovery and high availability

Know how to restore a dropped table and how long it takes. Time travel helps with recent mistakes, but it is not a backup, for the same reasons that a snapshot is not a backup. Keep a copy in another region or account, and test a restore before you need one.

Vendor lock-in and portability

Open table formats reduce lock-in at the storage layer: your data stays in open files you can read with another engine. They do not remove it everywhere. SQL dialects, security setups, catalogs and BI models still tie you to a platform. Ask any vendor one question: "If we leave, what do we take with us, and in what format?"

Team skills and organizational fit

This factor is often skipped, and it often decides the outcome.

Warehouse: fits teams of analytics engineers, BI developers and SQL-heavy analysts. Most of the work is modeling and SQL.
Lake: needs data engineers, platform engineers and data scientists comfortable with Python, Spark and cloud storage.
Lakehouse: needs a cross-functional platform team plus strong governance discipline. Without both, it drifts toward a swamp.

Change management matters too. Business users do not care about table formats. They care that "revenue" means the same thing everywhere and that the dashboard is right at 9 a.m. Win that trust first, and people will use the platform.

How to choose: a simple decision framework

Use your workloads, governance maturity, team skills and total cost to pick one of four patterns.

Choose	When	Watch out for
Data warehouse	Governed financial and operational reporting, predictable SQL speed, mostly structured data	Rising compute bills and slow onboarding of new sources
Data lake	Cheap, flexible retention of raw data for data science, logs or experiments	Turning into a swamp without owners and quality checks
Data lakehouse	BI and machine learning must use the same data, you want open storage, and you can staff a platform team	Complexity and the cost of running it well
Hybrid	An existing warehouse stays the trusted reporting layer while a lake handles raw data and ML	Duplicated data and pipelines to keep in sync

Many organizations already run the hybrid pattern: land everything in a lake, refine it, then serve curated tables through a warehouse. That is a sound design, not a failure to choose.

Two quick examples

A 20-person online shop pulls data from its store platform, two ad accounts and its accounting tool. It wants one sales dashboard that finance trusts. That is a warehouse.

A software company wants the same dashboards, plus app logs and support chats for an AI help bot. It already has two data engineers. That points to a lakehouse, or a lake beside its existing warehouse.

A note for small businesses

If your data fits comfortably in one database and your goal is reliable reporting, start with a warehouse. That might be a managed cloud warehouse, an open-source database such as PostgreSQL, or an analytical one such as ClickHouse. Add a lake when you have data that does not fit, such as large logs or documents for AI. Consider a lakehouse when you have both the need and the people. For the wider case on shared infrastructure in a small team, see virtualization for small business.

The vendor landscape in 2026

The labels blur in 2026. Warehouse vendors added open table formats, and lakehouse vendors added warehouses. This neutral map uses each vendor's own wording, as of October 2026. It is not a ranking.

Platform	Started as	Lakehouse support
Snowflake	Cloud data warehouse	Iceberg tables, Horizon Catalog
Databricks	Spark platform	Delta Lake, Unity Catalog, SQL warehouses
Google BigQuery	Serverless warehouse	Apache Iceberg managed tables
AWS	Redshift warehouse plus S3	S3 Tables (Iceberg), Redshift Iceberg support
Microsoft Fabric	Unified analytics platform (2023)	OneLake (Delta or Iceberg tables)
DuckDB and DuckLake	Open-source, single machine	DuckLake format, metadata in SQL

A few details behind the table, as of October 2026:

Snowflake now calls itself the "AI Data Cloud". Its Iceberg tables have been generally available since June 2024.
Databricks calls itself a "unified, open analytics platform".
Google renamed BigLake to "Lakehouse" in April 2026.
Amazon Redshift can update and delete rows in Iceberg tables, not only read them.
Microsoft Fabric OneLake stores tables in Delta Parquet or Iceberg format. Microsoft says it has no current plans to retire Azure Synapse Analytics, but its analytics roadmap now centers on Fabric.
DuckLake reached version 1.0 in April 2026. Open-source databases such as ClickHouse and PostgreSQL remain solid warehouse options too.

Names and features change fast. Check each vendor's docs before you decide.

Common myths and mistakes

"A lakehouse is always cheaper." Storage is cheaper. Engineering and operations often cost more. Compare total cost, not storage price.
"A warehouse cannot handle AI." Many teams train models on warehouse tables, and the major cloud warehouses support Python, vectors or AI functions as of October 2026. Check what yours does before you migrate.
"A lakehouse removes the need for data modeling." The gold layer is a data model. Skip it, and every analyst builds their own version of the truth.
"Schema-on-read means no governance." It means you apply the structure later. You still need owners, definitions and access rules.
"One platform must replace the other." Hybrid designs are common and sensible. Replace a working warehouse only when it blocks a real use case.
"Buying a lakehouse solves data quality." Quality comes from tests, owners and contracts. A new platform moves your quality problems to a new place.

A practical migration path

Whatever you choose, roll it out in steps. Prove each one before you build the next.

Inventory. List sources, users, workloads, freshness needs (how old the data may be) and compliance rules.
Classify data. Raw, semi-structured, unstructured, and business-critical.
Pick priority use cases. BI, machine learning, real-time or self-service. Choose one or two to start.
Choose a pattern and an operating model. Decide who owns the platform, who owns each dataset and who approves changes.
Build a governed MVP. A minimum viable product: one use case, end to end, with named owners and quality checks.
Measure. Cost, query speed, data freshness, adoption and the number of data incidents.
Expand. Add sources and teams only after governance and pipeline reliability are proven.

The risky bit, and how to roll back

The biggest risk in any migration is a quiet number change. For example, a report moves to the new platform and its total shifts by 3 percent. Nobody notices for a month. Run the old and new systems in parallel for at least one full reporting cycle, such as a month-end close. Reconcile the key totals every day. Keep the old system read-only, not deleted, until the business signs off. If the numbers do not match, you switch the reports back and fix the gap. That is your rollback plan.

FAQ

Is Snowflake a data warehouse or a data lakehouse?

Both, by design. Snowflake began as a cloud data warehouse and now calls itself the "AI Data Cloud". Its native tables work like a warehouse. Its Apache Iceberg tables keep data in open files, on your own cloud storage or on Snowflake storage, which is the lakehouse pattern.

Is Databricks a data warehouse or a lakehouse?

Databricks describes itself as a lakehouse platform, and it is the company that made the term popular. It also offers a data warehouse on top: Databricks SQL, which runs "SQL warehouses" for BI tools. Databricks argues that a lakehouse makes the best warehouse. Read that as a vendor position, not a neutral verdict.

What is the difference between a data lake and a data lakehouse?

A data lake is storage for raw files. A lakehouse adds a table format and a catalog on top, which give transactions, schema rules, versioning and access control. In short, a lakehouse is a lake you can trust for reporting.

Is a data lakehouse cheaper than a data warehouse?

Not always. Storage is cheaper, but compute, engineering and operations often cost more. For high-concurrency, well-structured reporting, a warehouse can cost less in total. Compare full costs for your own workloads before you decide.

What is the difference between a data warehouse and a data lakehouse?

A data warehouse stores structured data in the vendor's own format and is built for fast, consistent SQL reports. A data lakehouse stores data in open files on cheap cloud storage and adds warehouse features on top. The warehouse is simpler to run. The lakehouse is more flexible and suits machine learning, but it needs a stronger team.

Is a data lake an ETL tool?

No. A data lake is a place to store data. ETL (extract, transform, load) is a process that moves and cleans data. A lake often sits in the middle of that process: raw data lands there first, and later jobs clean it. That pattern is closer to ELT, because the data loads before it is transformed.