Adopting a data lakehouse doesn’t mean retiring the cloud data warehouse on day one. Most enterprise data teams end up running both, because the warehouse still does some jobs well and a data lakehouse built on Apache Iceberg does others better and more cheaply. The real decision is matching each workload to the platform that fits it.
As we’ve noted, the data lakehouse itself is being surpassed in various ways, with new technologies being built on top of it, but within this context, the lakehouse is still the foundation upon which these new developments are built. For that reason, the lakehouse is an important building block, as is the data warehouse that acts as a source for data and context that many organizations use as their starting point.
This article walks through the data warehouse’s remaining strengths in this scenario, the cost point where it starts to outpace the value it delivers, and the federated query path that lets you move workloads to open Iceberg tables one at a time instead of through a single disruptive migration.
Key takeaways
- A lakehouse doesn’t force you to abandon the warehouse. In fact, the two can run side by side while workloads migrate gradually, each handling the workloads it’s best suited for.
- Cloud data warehouse costs often scale faster than query volume because of egress fees, idle clusters, and over-provisioning for peak concurrency.
- Apache Iceberg brings warehouse-like schema enforcement, ACID transactions, and time travel to data on open storage, without requiring it to live inside a closed, proprietary system first.
- Federated query access lets teams keep high-concurrency BI on the warehouse while moving large-scale, cost-sensitive workloads to open Iceberg tables.
- Testing workload fit in place, before migrating anything, gives you cost and performance evidence and reduces project risk compared with a full cutover.
What a cloud data warehouse still does well
A cloud data warehouse earns its keep on a specific set of workloads, specifically structured data that rarely changes shape. Data warehouses like Snowflake, Redshift, and BigQuery are built around a closed, managed storage layer, and the tight coupling between the SQL engine and that proprietary storage format is the reason they’re fast and predictable for finance close processes, executive dashboards, and other workloads where hundreds of analysts hit the same curated tables at once.
That tight coupling also has a tradeoff. A side-by-side comparison of data warehouse, data lake, and data lakehouse design shows that the warehouse’s performance comes from proprietary storage formats and managed indexing, not from the SQL engine alone. That’s a reasonable tradeoff for structured, governed reporting but it becomes a liability the moment your workloads outgrow that narrow lane, which is usually when the warehouse bill starts outpacing the value it delivers.
Where the warehouse starts to cost more than it delivers
The warehouse doesn’t fail all at once. Instead, it fails at the margins first, for example the ad hoc query that scans more data than it needs to, the nightly batch job that reserves a cluster it barely uses, the semi-structured event data that gets flattened into rigid tables just so it can be queried at all, which amounts to paying warehouse-grade compute rates for workloads an open data lakehouse can run for a fraction of the cost.
Costs that scale faster than query volume
Cloud data warehouse costs tend to scale faster than the actual volume of useful work, because the pricing model charges for provisioned compute and stored copies, not for query efficiency. Clusters that aren’t configured to auto-suspend still bill while idle. Egress fees apply when data has to move between regions or services. Over-provisioning for peak concurrency means you’re paying for headroom most of the day. If you’re not sure whether your organization has outgrown this model, a quick check on cloud data warehouse costs covers the warning signs, including rising spend without matching query growth, teams duplicating the same tables across environments, and engineers spending more time tuning clusters than building new analytics.
Data copies, lock-in, and stale pipelines
The second cost is less visible on the invoice but more corrosive over time. Centralizing everything into one warehouse means copying data out of source systems, through pipelines, into warehouse-native tables. Each copy is a new entity to maintain, a new point of staleness, and a new dependency on the warehouse’s proprietary format. Teams that try to solve data sprawl by consolidating harder often find that the “fix” multiplies the number of copies instead of reducing it, and the pipelines meant to keep those copies current become their own maintenance burden.
What a lakehouse adds without replacing the warehouse
A data lakehouse doesn’t ask you to abandon the warehouse model. Instead, it extends warehouse-like structure and performance onto data that already lives in open storage. By pairing Apache Iceberg tables with a distributed SQL engine, a lakehouse can deliver the warehouse functionality teams rely on, including schema enforcement, ACID transactions, and fast concurrent reads, without requiring every dataset to be copied into a closed, proprietary system first.
The performance gap that used to separate lakehouses from warehouses has narrowed considerably. Pairing lakehouse object storage with a performant query engine can match or beat warehouse query performance for many analytical workloads, particularly ones involving large scans, semi-structured data, or data that spans multiple cloud platforms and regions. That changes the question from “can a lakehouse match my warehouse’s performance” to “which workloads need the warehouse, and which ones are better served by open tables you can query from anywhere.”
The real decision is workload fit, not a platform war
Adopting a lakehouse involves determining which workloads genuinely require the warehouse’s tightly managed performance, and which ones are running workloads better suited to open Iceberg tables than to warehouse-grade compute. As we’ve noticed, customers have cut costs by 50% compared with a cloud data warehouse, and queried 2.5x faster than open-source Trino, all without a wholesale migration off existing platforms.
Workloads that still belong in a warehouse
Keep workloads in the warehouse when it makes sense, especially when the data is small and stable enough that storage format barely matters, or when a regulatory or contractual requirement ties the data to that specific platform. These are the workloads where the warehouse’s managed performance justifies its cost.
Workloads ready to move to Iceberg
Move workloads to Iceberg tables when they involve large volumes of semi-structured or rapidly growing data, when multiple teams or tools need to query the same data without copying it into each platform separately, or when the pipelines feeding the warehouse are themselves becoming a maintenance burden. That fit depends on write patterns as much as the data’s shape. Iceberg’s optimistic-concurrency model is built for batch and merge-style writes, so a workload that depends on frequent small-row writes may need a different approach than a straight lift to Iceberg tables, even if its data otherwise looks like a good candidate. Starburst delivers data warehouse functionality without the warehouse’s cost structure for the workloads that do fit this pattern, running SQL directly against open tables instead of a proprietary store. Iceberg itself is a big part of why this works. Its brings schema evolution and time travel onto lake storage, two capabilities that used to be warehouse-only features.
Querying both in place, without a migration project
None of this requires choosing one platform and migrating everything to it on a deadline. Federated query access built on an open data lakehouse lets you query the warehouse and lakehouse from the same place, so analysts and agents don’t need to manage data migration before they can explore the data. All data is reachable through the same SQL layer, which means the migration happens one workload at a time, on your schedule, instead of as a single disruptive cutover with a hard go-live date.
A practical way to test the move before committing
The lowest-risk way to validate this approach is to query both platforms in place before moving anything. Direct a federated query engine at your existing warehouse and at a set of Iceberg tables, run the workloads that are candidates for migration against both, and compare cost and performance directly. That gives you cost and performance evidence before you commit engineering time to the move.
Next steps
Start by identifying the workloads where your warehouse spend has stopped tracking with the value you get from it. That’s usually where a lakehouse argument is strongest.
This guide to reducing your cloud data warehouse spend walks through those cost and performance comparisons in more detail, including the role Iceberg tables and federated query access play in a plan that doesn’t require a disruptive cutover.
FAQs
Do you have to migrate off your cloud data warehouse to adopt a lakehouse?
No. Lakehouse adoption works best as a gradual, workload-by-workload migration rather than a wholesale one. High-concurrency BI dashboards and other workloads that benefit from the warehouse’s tightly managed performance can keep running there, while large-scale or cost-sensitive workloads move to open Iceberg tables. A federated query layer lets both platforms coexist until the economics of each workload argue for moving it.
Which workloads should stay in a warehouse, and which belong on a lakehouse?
Keep workloads in the warehouse when your data is already there, and when the underlying data is small and stable, or when a regulatory requirement ties the data to that platform. Move workloads to Iceberg tables when they involve large or semi-structured data, when multiple teams need to query the same data without copying it, or when the pipelines feeding the warehouse have become a maintenance burden themselves.
Is a data lakehouse cheaper than a cloud data warehouse?
For many workloads, yes, a lakehouse built on Apache Iceberg and a distributed SQL engine can match or beat warehouse costs because it avoids storing redundant copies and paying for proprietary indexing on data that doesn’t need it. The cloud data warehouse infographic walks through the warning signs that a workload has outgrown warehouse economics: rising spend without matching query growth, duplicated tables across environments, and engineers tuning clusters instead of building new analytics.
How can a team query a warehouse and a lakehouse together without building new pipelines?
A federated query engine connects directly to both the warehouse and Iceberg tables on object storage, so analysts run SQL against either one from the same place without copying data between them. Federated query access built on an open data lakehouse describes how that single SQL layer removes the need for a separate pipeline to make warehouse and lake data queryable together.
What is Apache Iceberg, and why does it matter for this decision?
Apache Iceberg is an open table format that brings warehouse-like performance, including schema enforcement, ACID transactions, and time travel to data stored on object storage. This capability lets a lakehouse act like a warehouse without requiring data to live inside a closed, proprietary system first. Its concurrency model is tuned for batch and merge-style writes, so workloads built around high-frequency small writes are worth testing before assuming a one-to-one swap.
Is the lakehouse enough today?
Increasingly, the lakehouse is one building block of a larger strategy that serves both human users and AI agents. The lakehouse originally emerged in the context of data analytics, and that still matters today. Alongside that, lakehouses, especially those based on Iceberg, play a key role in the data foundation underpinning AI workloads and that adds to the lakehouse other requirements, like context and business intelligence that AI requires to maintain accuracy.
