The choice between a data lake, a data warehouse and a lakehouse usually arrives framed as a question of volume: how many terabytes are stored, and how fast that number is growing. That framing produces the wrong answer often enough to be worth correcting, because none of the cloud engines most teams end up on charge primarily for stored volume. They charge for how the data gets read.
Amazon states it plainly in the Redshift Serverless billing documentation: the minimum charge is 60 seconds of resource usage, metered per second, and storage is billed separately by GB per month. Google's BigQuery cost guidance is more pointed still, since on-demand billing counts the logical bytes read across the columns a query references, and a LIMIT clause on a non-clustered table does not reduce that number at all. Snowflake, per its warehouse documentation, bills compute per second with a 60-second minimum every time a warehouse starts.
Three vendors, three billing mechanics, one shared conclusion: the shape and the cadence of the queries decide the invoice. So the useful question covers access rather than size. Who reads the data, how often, in what shape, and how much of it does each read touch?
What a data lake, a data warehouse and a lakehouse actually are
A data warehouse stores data that has already been cleaned, joined and modeled. Structure is enforced on write, so a row that does not fit the schema is rejected at load time rather than discovered by an analyst six months later. That discipline makes a warehouse dependable for reporting, and also makes it slow to accommodate a new source nobody planned for.
A data lake inverts the trade. Files land in cloud object storage in whatever format they arrive, from Parquet and JSON to audio and scanned documents, and structure gets applied when something reads them. Storage is cheap and ingestion is nearly frictionless. What a plain lake lacks is transactional guarantees: two jobs writing the same dataset can leave a reader seeing half of each, and nothing stops a producer from silently changing a column type.
A lakehouse closes that gap with a transactional metadata layer over open files in object storage. Databricks defines it in its own documentation as a data management system that combines the benefits of data lakes and data warehouses, and in its implementation Delta Lake supplies an optimized storage layer with ACID transactions and schema enforcement, while Unity Catalog supplies fine-grained governance and lineage across transformations. The files stay in the object store they were already in, and the guarantees are what get added.
Why the query pattern decides more than the data volume
Take two companies holding the same 40 TB. The first runs a nightly batch that scans everything once and publishes 200 aggregated tables, so it wants sustained compute for a short window. The second serves a dashboard that 400 people refresh through the working day, each refresh touching a handful of columns across a wide table, so it wants small, fast, highly concurrent reads and pays a penalty for every unnecessary column.
Those two profiles land very differently on each pricing model. Under BigQuery's on-demand model, the second company is billed for the bytes in the columns its queries reference, so a SELECT * behind a dashboard multiplies the bill by the width of the table, and partitioning plus clustering bring it back down. Under Snowflake's per-second billing, the 60-second floor on every warehouse resume means a workload made of hundreds of short bursts can cost more than one long-running job moving the same data. Redshift Serverless adds a detail that surprises people: cancelled queries are still billed for the time they ran, and connection-pool health checks count as billable activity, so an idle application with an aggressive keep-alive generates cost with no user behind it.
None of that correlates with how much data is stored. It correlates with concurrency, column width, refresh frequency and how long compute stays warm. Teams that inventory those four properties before choosing an architecture tend to arrive at a defensible answer, while those starting from the terabyte count usually over-provision and negotiate the bill afterwards.
Which architecture fits which workload
The decision gets much easier when it is made per access pattern rather than for the company as a whole. Most mature platforms end up running more than one of these at once, which is a normal outcome rather than a sign of indecision.
| Access pattern | What it needs | Where it fits | Cost of the wrong call |
|---|---|---|---|
| BI and reporting on agreed metrics | Modeled tables, enforced schema, concurrent reads | Data warehouse, or a governed lakehouse layer | The same metric gets rebuilt three ways and none reconcile |
| Exploratory analysis on raw or semi-structured data | Cheap storage, schema on read, no load-time rejection | Data lake, or the raw layer of a lakehouse | Ingestion cost and rejected rows for unmodeled data |
| ML training on files, text, images or audio | Direct file access, versioning, reproducible snapshots | Lakehouse with an open table format | Training-set copies drift out of sync with production |
| Streaming and near-real-time serving | Incremental writes, frequent commits, low latency | Lakehouse, or a warehouse with streaming ingestion | Micro-batches trigger the per-start compute floor every cycle |
| Regulatory retention and archive | Durable object storage, immutability, low cost per TB | Data lake, storage tier only | Warehouse storage rates for data queried twice a year |
| Several teams owning their own datasets | Shared catalog, per-domain permissions, contracts | Lakehouse with governance, often as data mesh | A central team gates every schema change |
Open table formats, catalogs and what they changed about lock-in
The reason a lakehouse is practical now is that open table formats matured. Apache Iceberg, Delta Lake and Apache Hudi all put a metadata layer over files in object storage so that a directory of Parquet becomes a table with real guarantees. Iceberg's own documentation describes schema evolution, hidden partitioning, time travel through branching and tagging, and ACID behaviour, with engine support spanning Apache Spark, Apache Flink, Apache Hive and Kafka Connect, plus third-party integrations that include Trino, Presto, DuckDB, Snowflake, Amazon Athena and BigQuery.
That engine list is the part with commercial consequences. When several engines read the same tables in place, the storage layer stops being the thing that locks a company in, and a team can model in one engine, train models in another and serve BI from a third without duplicating the data.
Lock-in moved rather than disappeared, and it now sits in the catalog, which decides which engines see which tables, who holds permissions, and how lineage is recorded. A proprietary catalog over open files still constrains the choices available later, so evaluating a platform on its catalog and permission model, alongside its query performance, is what separates a durable decision from one that has to be revisited in two years.
Snowflake, BigQuery, Redshift and Databricks: what each one assumes
Every platform in this category embeds assumptions about how a team works, and friction usually comes from a mismatch there rather than from a missing feature.
Snowflake separates storage from compute and expects workloads to be isolated into separately sized virtual warehouses, so an ETL job never competes with a dashboard for resources. Billing is per second with a 60-second minimum on each start, which rewards consolidating bursty work and suspending idle warehouses aggressively.
BigQuery removes cluster sizing entirely. There is nothing to provision, and the discipline moves into query and table design, since on-demand cost follows the bytes read across referenced columns. Teams that partition, cluster and select narrowly do well. Teams that hand analysts a wide table and a BI tool emitting SELECT * do not.
Redshift offers provisioned nodes or the serverless model billed in RPU-hours, with Redshift Managed Storage charged separately by GB per month. It rewards deliberate physical design, sort and distribution keys and workload management among them, and integrates tightly with the rest of an AWS estate.
Databricks starts from code rather than SQL alone, pairing Spark with Delta Lake and Unity Catalog. It suits organizations whose data engineering, machine learning and BI live in one platform, and asks for engineering maturity in exchange.
None of these is the correct answer in general, and any comparison producing a single winner has quietly assumed one workload. BIX Tech works across multiple data, cloud and engineering stacks precisely because the right choice changes with the access pattern, the skills on the team and the estate already in place.
How to start without rebuilding what already works
Begin by writing down the access patterns that exist today, with the four properties that drive cost attached to each: concurrency, column width, refresh frequency and retention. That document is short, and it usually reveals that two or three patterns account for most of the spend while a long tail accounts for most of the complexity.
Check next whether a warehouse is needed at all, since plenty of companies run reporting on an operational database well past the point where it is comfortable and well before the point where it genuinely limits them. When the answer is yes, land raw data in object storage in an open table format first and model on top of it, so the modeling layer can be rewritten later without moving a byte.
Instrument cost per query and per consumer from the beginning, because the aggregate monthly figure hides which pattern is expensive. Layered modeling conventions and a transformation tool with tests keep the modeled layer trustworthy as it grows, and a catalog with real permissions keeps the raw layer usable by more than one team.
Where to go deeper
The comparison has narrower angles worth reading. The framing of data lake against data warehouse, and when the answer is both covers the hybrid case in detail, while choosing between lakehouse, data lake and data warehouse for a specific business works the same decision from the commercial side. For the skeptical read, whether the lakehouse is a genuine evolution of modern analytics is worth the time, and building a lakehouse architecture from scratch turns the concept into an implementation blueprint.
Ownership is the second question, and it is organizational as much as technical. The comparison of data mesh against the lakehouse sets out where the two overlap, and the three-way version covering data mesh, lakehouse and data fabric adds the term most likely to appear in a vendor deck. Before committing, what a data mesh actually requires and the harder question of whether data mesh suits every company are both more useful than the enthusiasm the term attracts.
Inside the platform, layering and modeling conventions do the work. Medallion architecture and what the bronze, silver and gold layers are for is the most widely adopted convention, and teams retrofitting rather than starting fresh will get more from introducing dbt into an existing data warehouse. On the platforms themselves, what Snowflake is and where it fits and the Databricks lakehouse architecture guide cover each side, the architecture-level comparison between Databricks and Snowflake is the one to read before drawing up a shortlist, and Azure Databricks against Microsoft Fabric serves teams already committed to Azure.
Cost control is where these decisions become visible. BigQuery pricing and how to keep queries under control and the follow-up on partitioning, clustering and BI Engine address the bytes-read model directly. For the opposite end of the scale, how far Postgres goes before a warehouse is justified and when DuckDB can stand in for one are the two posts that most often save a project from buying infrastructure it does not need yet.
The data lake, data warehouse and lakehouse question resolves once it is asked per access pattern instead of per company. Storage is the cheapest part of every one of these platforms, and compute that answers queries is the expensive part, which is why the concurrency, the column width and the refresh frequency of each workload predict both the cost and the right architecture better than the size of the dataset ever will. Most estates end up with a governed modeled layer for reporting and open tables underneath it for everything else, reached by measuring how the data is read rather than counting how much of it there is.
Whichever option you land on, compute behavior matters as much as storage, and warehouses that adjust their own performance and cost are explored in adaptive data warehouses and how they work.
If your company is weighing a data lake, a data warehouse or a lakehouse, or paying more than expected for a platform that was sized against volume instead of access patterns, our specialists can help map the workloads and settle the architecture before the bill settles it for you. Talk to our team and move your data maturity forward. ⬇️
FAQ: frequently asked questions
What is the difference between a data lake, a data warehouse and a lakehouse?
A data warehouse stores modeled data with the schema enforced on write, which suits reporting on agreed metrics. In a data lake, raw files sit in object storage and the schema is applied on read, which suits exploration and machine learning. The lakehouse adds a transactional metadata layer over those files, giving ACID guarantees and schema enforcement on open storage.
Do I need a data lakehouse, or is a data warehouse enough?
A warehouse is enough when the workloads are BI and reporting on structured sources a team already models. The lakehouse earns its place when semi-structured or unstructured data, machine learning on files, or several engines reading the same tables enter the picture. Many estates run both, with a governed modeled layer over open tables underneath.
How much does a data lakehouse cost compared with a data warehouse?
Cost tracks compute and access patterns rather than stored volume. BigQuery on-demand bills the logical bytes read across the columns a query references, Snowflake bills compute per second with a 60-second minimum per warehouse start, and Redshift Serverless bills RPU-hours with storage charged separately by GB per month. Concurrency, column width and refresh frequency drive the invoice.
Which is better, Snowflake, BigQuery, Redshift or Databricks?
No one of them is better in general, because each assumes a different way of working. Snowflake expects workloads isolated into sized warehouses, BigQuery moves the discipline into query and table design, Redshift rewards deliberate physical modeling inside AWS, and Databricks suits code-first engineering with machine learning alongside BI.
How do you start migrating to a lakehouse architecture?
Document the existing access patterns first, recording concurrency, column width, refresh frequency and retention for each. Land raw data in object storage in an open table format such as Iceberg or Delta Lake, model on top of it, and instrument cost per query and per consumer from the first workload so the expensive pattern is visible early.
