Data Lake or Warehouse: You Are Choosing When to Pay the Modeling Cost

The difference that matters is when you pay the modeling cost

The textbook distinction is schema on write versus schema on read. A warehouse makes you model the data before loading it. A lake takes it raw and makes you model at query time.

Translated into calendar, that is the whole argument. A warehouse front-loads the modeling into weeks 1 through 12 and gives you clean answers afterwards. A lake defers modeling until somebody asks a question, giving you data on day one and a mess to sort out per question.

Everything else in the comparison, file formats, storage cost, open table standards, is real engineering detail and close to irrelevant to a 200-store retailer's timeline.

The two time profiles

Warehouse-first. Weeks 1 to 3 on source analysis. Weeks 4 to 10 on dimensional modeling and ETL development. Week 11 on first load. Week 12 on first answer. Then every subsequent answer is fast, because the modeling is done.

Lake-first. Day 1 on raw ingestion. Day 3 on first ugly answer. Week 2 on the first reconciled answer. Then every subsequent answer costs a little modeling work, and if you never consolidate that work, question twenty costs about what question two cost.

The warehouse profile is a bet that you know the questions in advance. The lake profile is a bet that you will discover them and can afford the marginal cost.

For mid-market retail the lake profile wins on one basis: projects that show an answer in week two survive, and projects that show nothing until week twelve get cancelled at week nine. Speed to first answer is not a technical preference. It is political survival, and it is the reason so many warehouse-first projects never reach their fast phase.

Where the lakehouse lands

The current default is neither. Land raw into cheap storage, then build modeled tables on top of it incrementally, in the order questions arrive.

Snowflake, BigQuery, and Databricks all support this pattern now. The naming argument between them is a vendor concern. What you are choosing is a sequence, and the sequence is: raw first, model as needed, consolidate the modeling into a shared layer as soon as two questions need the same definition.

That last clause is what keeps a lake from becoming a swamp. The swamp is not caused by raw data. It is caused by the same metric being defined differently in eleven queries, because nobody promoted the definition to a shared place the second time it was needed.

Most mid-market retailers do not need a lake in the strict sense

The original case for a lake was volume and variety: petabytes, unstructured data, machine-generated streams, schemas that could not be known in advance.

A 200-store retailer with three years of transactions has a few hundred gigabytes of well-structured relational data with schemas that have not changed since 2019. That fits comfortably in a warehouse, and would have fit in a large Postgres instance.

What those retailers actually want from the word "lake" is not the architecture. It is permission to load data before finishing the model. You can have that in any of the three platforms, and calling it a lake is a labeling decision that has cost more projects a quarter of debate than it has saved anyone a dollar of storage.

The decision rule

Three questions settle it in an afternoon.

Do you know your twenty questions today? If yes, and they are stable, warehouse-first modeling is defensible and will produce a cleaner result. If your questions change quarterly, front-loaded modeling will be rebuilt before it is finished.

Is any meaningful source unstructured or semi-structured? Shelf images, sensor feeds, unbounded JSON from a vendor API. If yes, you need lake storage for those specifically. Most retailers have one such source and try to architect the whole platform around it.

What happens to this project if there is no answer by week twelve? If the honest answer is that the funding gets questioned, the sequence is decided for you. Land raw, answer early, model as you go.

In mid-market retail the third question decides it most of the time, and it is the one that never appears on the architecture scorecard.

What actually gets built

The pattern that works, regardless of which vendor's logo is on it:

Raw zone. Every source, landed as it arrives, no transformation, retained. Hours of work per source. This is your lake.

Reference layer. The six small tables that make joins possible: fiscal calendar, store hierarchy, category hierarchy, SKU cross-reference, store open and close dates, plan by store and week. Days of work, done once, and the single highest-return object on the platform.

Metric layer. Canonical definitions, one per KPI, promoted from query code the second time a definition is reused. Grows continuously. This is your warehouse, built in the order questions arrive rather than all at once.

Serving. Whatever puts the number in front of the person: BI, alerts, cards, an API.

Nobody in the business will ever ask which of those four is the lake. They will ask why margin by category takes two weeks, and the answer will always be the metric layer.

A note on cost, since it comes up

Storage is not the variable. A few hundred gigabytes costs tens of dollars a month on any of the three platforms. Retailers who choose an architecture on storage price are optimizing a rounding error.

Compute is the variable, and it is driven by query patterns rather than architecture. Unbounded exploratory queries over raw tables cost more than the same questions answered from modeled tables, which is a genuine argument for consolidating the metric layer early, and a poor argument for spending three months on modeling before loading anything.

The dominant cost on both paths is people, and people cost is a function of elapsed months. That is the strongest financial argument for the sequence that answers a question in week two.