What is a data lakehouse, and do you actually need one?

A data lakehouse is a single storage layer that behaves like a data warehouse for your structured tables and like a data lake for everything else. One copy of the data, serving both BI and AI, with ACID transactions on cheap object storage underneath. It's the architecture that replaces the "warehouse for reporting, separate lake for data science" split most businesses are living with.

You probably need one if your AI roadmap includes anything unstructured, if your cloud data bill is creeping past $200k a year, or if your data science team keeps exporting CSVs from the warehouse because the warehouse wasn't designed to serve them.

You probably don't need one if you're doing BI and nothing else, your data fits in under 1TB, or your current warehouse costs are trivial. Buying a lakehouse to solve a problem you don't have is one of the more expensive mistakes in the data stack.

What a lakehouse actually is

Under the hood, a lakehouse is three things stacked:

Object storage. S3, Azure Blob, GCS. Cheap, infinite, but not queryable on its own. This is where the raw bytes live, in open file formats (usually Parquet).

A table format. Apache Iceberg, Delta Lake, or Apache Hudi. This is the piece that makes a folder of Parquet files behave like a table. ACID transactions, time travel, schema evolution, metadata that lets query engines skip 99% of the files. Without this layer, you have a lake. With it, you have a lakehouse.

Compute engines. Spark, Trino, DuckDB, Snowflake's external tables, BigQuery's external tables, Databricks SQL. These are the query engines that read the table format. The point of the lakehouse pattern is that you can run multiple engines against the same data, so BI tools and ML pipelines and ad-hoc exploration all hit the same source of truth.

The combination gives you warehouse-like performance and governance on lake-like storage economics. For the right workload profile, that's a meaningful win.

The pitches vs the reality

Every lakehouse vendor will tell you three things: it's cheaper, it's faster, and it unifies BI and AI. Each is true in specific cases and misleading in others.

Cheaper. Only if your current warehouse bill is dominated by storage or by duplicate data. If you're paying Snowflake mostly for compute (which is the common case), moving to a lakehouse doesn't cut your compute bill. It just lets you put cold data on cheaper storage.

Faster. Only for workloads the table format is optimised for. Iceberg metadata pruning on a well-partitioned table is genuinely fast. Tiny random lookups against a poorly partitioned table are still slow, lakehouse or not.

Unified BI and AI. Only if you actually have AI workloads that need unstructured or semi-structured data, and those workloads are currently pulling CSVs out of the warehouse. If your "AI" today is a handful of propensity models trained on tabular data, a warehouse already serves you fine.

The honest version of the pitch: a lakehouse makes sense when you have enough scale that storage cost matters, enough variety in workloads that one engine can't serve them all, and enough AI ambition that the data science team is currently the biggest exporter of data out of the warehouse.

When a lakehouse is the right call

Three rough tests. If at least two are true, start the conversation.

1. Data volume over 5TB, growing fast. The economics of Parquet-on-object-storage vs warehouse-native storage genuinely bend at this scale.
2. AI / ML workloads are a material part of the roadmap. Not one experimental model, but a pipeline of them, with feature stores, retraining, and experiment tracking.
3. Multiple query engines already in play. If you're running Spark alongside a warehouse, or a data science team is buying their own Databricks cluster, you already have the scattered-compute problem a lakehouse exists to solve.

When a warehouse is still the right call

• You're under $5m in revenue, or data is not the product.
• Reporting and BI are 90%+ of the workload.
• Your total cloud data bill is under $150k a year. The migration alone will cost more than the savings for at least 18 months.
• Your team is three data engineers, not thirty. A managed warehouse (Snowflake, BigQuery, Redshift) is a better match for operator count.

The practical middle

Most Australian mid-market businesses we work with don't need to choose between "full lakehouse" and "pure warehouse." They need a lakehouse-shaped data platform with a managed warehouse service on top. Pick a table format (we default to Iceberg, because of the open ecosystem). Pick a catalog (Glue, Unity, or Polaris). Point BigQuery or Snowflake at it for BI, point Databricks or Spark at the same tables for ML. One copy of the data, multiple engines, clean governance.

That pattern is called "open lakehouse" in vendor decks. In practice it's the sanest default for mid-market AI work in 2026: buy the serving layers, own the storage and the table format, keep options open.

What it takes to ship

• Greenfield build, 4-8 domain tables, managed cloud: 10-14 weeks to first use case.
• Migration from an existing warehouse, 20-50 tables, preserving access patterns: 14-24 weeks, depending on how many consumers need to switch query patterns.
• Adding a lakehouse alongside an existing warehouse (hybrid): 6-10 weeks, scoped to the AI-first tables.

If a vendor proposes a $30k lakehouse, they're selling you an Iceberg setup script, not a platform. If a vendor proposes a six-or-seven-figure lakehouse for a business under $100m revenue, they're selling you someone else's problem.

One buying rule

Don't buy a lakehouse. Buy the AI use case that the lakehouse makes possible. If you can't name a specific model, a specific decision, a specific weekly workflow that'll change once the platform exists, the lakehouse is a solution looking for a problem. Name the use case first. Let it pull the platform into existence.