The choice between a data lake and a data warehouse starts with the business question, not the tool. If leadership needs the same twenty answers every month (revenue by channel, margin by product, churn by segment), a managed warehouse handles it and a lake only adds work. If the company needs to keep logs, documents, clickstream events and sensor data for questions it doesn't know how to ask yet, a warehouse alone gets expensive and cramped.
What changed in the last few years is that the two options stopped being mutually exclusive. You can now store data in an open format, on cheap object storage, and query it with a warehouse engine. That changes the decision, but it doesn't remove the starting question.
The difference that still holds
A data warehouse stores structured data with a schema defined at write time (schema-on-write): the sales table has columns, types and rules before it receives its first row. It's built for SQL, BI and recurring questions. BigQuery, Snowflake and Amazon Redshift are the most common examples.
A data lake stores raw files in object storage (Amazon S3, Google Cloud Storage, Azure Data Lake Storage) and applies the schema at read time (schema-on-read). It takes CSV, JSON, Parquet, images, PDFs, logs. It's cheap to store and flexible to explore, but it pushes quality and governance problems onto whoever consumes the data.
The paper that popularized the term lakehouse, published by Armbrust, Ghodsi, Xin and Zaharia at CIDR 2021, describes the two-tier architecture many companies ended up with: data lands in the lake, a subset is copied to the warehouse through ETL, and the two copies drift apart. The authors list the costs of that split: stale data, reliability issues between copies, higher total cost of ownership, vendor lock-in and limited support for data science.
What the lakehouse changed
The technical answer came from open table formats. Apache Iceberg and Delta Lake add a metadata layer on top of Parquet files in object storage, and with it ACID transactions, schema evolution, queries against earlier versions (time travel) and row-level deletes. In practice, files in a bucket start behaving like a table.
The three major cloud warehouses already read these formats:
- Snowflake made Apache Iceberg tables generally available in June 2024.
- Amazon Redshift queries Iceberg tables cataloged in AWS Glue, through Redshift Spectrum or Redshift Serverless.
- BigQuery offers BigLake tables for Apache Iceberg, with data stored in customer-owned buckets.
What this means for the decision-maker: storing data in Iceberg or Delta lowers lock-in risk, because another engine can read the same copy. The price is one more component to run: a catalog, compaction of small files, snapshot retention policies. For a small team, that matters.
The pricing model matters as much as the architecture
A lot of data decisions go wrong on the invoice, not on the diagram. The three vendors charge differently, and each model punishes a different behavior.
BigQuery. Under on-demand pricing, you're charged for the bytes each query reads: the first TiB per month is free, and the price list shows US$6.25 per TiB after that in regions such as us-central1. There's also capacity pricing, in slots. On-demand punishes queries that scan whole tables: a badly built dashboard that reads a large table on every refresh becomes a visible line on the bill. Partitioning by date and clustering on the most-filtered columns is usually the first saving.
Snowflake. Compute runs on virtual warehouses that consume credits billed per second, with a 60-second minimum each time a warehouse starts. What hurts here is warehouses left running idle and warehouses sized larger than the workload needs. A short auto-suspend and separate sizes for loading and for BI solve most of it.
Redshift. There are provisioned clusters, where you pay for running nodes, and Redshift Serverless, billed for capacity used (RPU-hours), per second with a 60-second minimum. AWS's own documentation warns about a cost that catches people off guard: connection-pool health checks, such as a periodic SELECT 1, are billed as normal usage. An application that keeps connections open can generate cost while nobody is querying anything.
None of these models is better in absolute terms. Steady, predictable load usually comes out cheaper on reserved capacity; irregular load with month-end spikes tends to favor on-demand or serverless. That's why it pays to measure your real usage profile before signing an annual commitment.
A decision checklist
Answer these before picking technology:
- What are the recurring questions? List the ones leadership and business units ask every month. If they all come from the ERP, CRM and finance, you're in warehouse territory.
- What kinds of data come in? Only tables from transactional systems, or also web and app events, logs, documents, audio, telemetry? Unstructured data at volume pulls toward a lake or lakehouse.
- Who consumes it? Analysts with SQL and a BI tool, or data scientists with Python and Spark training models? The second group benefits from direct access to open-format files.
- Who will run it? An Iceberg lakehouse needs real data engineering. If your data team is one person, a managed warehouse is the safer choice.
- Which cloud are you already on? Contracts, networking, identity and security that are already set up are worth money. On Google Cloud the short path is BigQuery; on AWS, Redshift and Athena.
- How much lock-in can you tolerate? If you want the option of switching engines in three years, storing in an open format now is cheap; doing it later is not.
- How do you handle privacy deletion requests? A request to delete personal data has to be honored in every copy. In a lake of loose files, finding and removing one customer's records is manual work; in a warehouse or an Iceberg or Delta table, it's a DELETE statement.
Three common scenarios
Mid-sized company with an ERP, a CRM and spreadsheets. A few hundred gigabytes, known questions, a small data team. A managed warehouse on the cloud you already use, an ingestion tool and a SQL modeling layer. A lake here is cost without return.
Digital retailer with clickstream, a catalog and recommendation plans. High-volume events, semi-structured data, data scientists who need raw history. Object storage with Iceberg tables, read by the warehouse for BI and by Spark or Python for models.
Manufacturer with sensors and legacy systems. High-frequency telemetry nobody queries in full, plus production and quality data management checks daily. Raw telemetry in the lake, aggregates by shift and by machine in the warehouse.
The most expensive mistake
Moving to a data lake expecting it to fix messy data. If today nobody knows which spreadsheet has the right number of active customers, a lake will store every wrong version, with much more room. The problem in those cases is governance: an owner for every important table, one definition per metric, a catalog that says where each number comes from. No architecture replaces that, and a lake without governance becomes what the industry calls a data swamp.
Next step
Before comparing vendors, gather the ten questions leadership asks most and mark, for each one, which system the data comes from and how often the answer needs refreshing. That one-page list will decide more than any performance benchmark, and it shows whether your problem is architecture or governance.
If you want help building that list and turning it into an architecture, that's the work we do in Data and AI. When the question is narrow, such as whether it's worth moving a warehouse to Iceberg, a short Cyborg Forge engagement measures cost and performance on your own data.