Three architectures, one decision. A practical way to pick by the questions your business asks, not by the vendor’s diagram.
In brief
- A data warehouse stores cleaned, structured data for reporting. A data lake stores raw data of any kind. A lakehouse tries to give you both in one place.
- None is “best”. Each fits a different kind of question.
- Choose by four things: what questions you ask, what data you hold, who asks, and how fast the answer is needed.
- Most organisations should start with the smallest design that answers their first real question, then grow.
Most “which architecture should we buy?” meetings begin with product names and end with a long slide of boxes and arrows. The room agrees on a design that looks modern, and six months later the finance team still cannot get a number it trusts.
The better question comes first: what do we need to be able to answer, and from which data? The architecture follows from that. It does not lead it.
What each one actually is
The three terms are often used loosely, so here is a plain version.
Data warehouse. A central store of cleaned, structured, agreed data, organised around business questions. Sales by region, stock by warehouse, cost by project. People trust it because someone has already decided what each column means. It is built for reports and dashboards.
Data lake. A large store that accepts data as it arrives: tables, files, logs, documents, sensor readings, text. Little is cleaned up front. It is cheap to fill and flexible, and it suits data scientists and teams who do not yet know what they will ask.
Lakehouse. A newer design that keeps raw and refined data in one platform, so that analysts and data scientists work on the same copy. It aims to combine the flexibility of a lake with the reliability of a warehouse.
| Data warehouse | Data lake | Lakehouse | |
|---|---|---|---|
| Data it holds | Structured, cleaned | Anything, raw | Both, layered |
| Best for | Reports, dashboards, finance | Exploration, ML, unstructured data | Mixed teams who need both |
| Strength | Trusted, consistent numbers | Flexible and cheap to fill | One platform for everyone |
| Risk | Slow to add new data types | Becomes a "swamp" without rules | More moving parts to run and govern |
| Typical user | Management, finance, operations | Data scientists, engineers | Analysts and data scientists together |
The real issue is not the architecture. It is the question.
The same company can need all three over time. What goes wrong is choosing one before the first business question is clear.
A lake built “so we can answer anything later” often answers nothing: the data is there, but nobody has agreed what it means, so every report starts with a debate. A warehouse built without looking at where the data actually lives takes a year to load and arrives after the decision was made. A lakehouse chosen because it sounds like the future may be more machinery than a ten-person data team can run.
So the sequence matters.
Four questions that choose the architecture
Ask these in order. Write the answers down before talking to any vendor.
1. What are the five questions management asks most, and answers least reliably?
If they sound like “How much did we sell, ship and bill this month?” or “Which branch is over budget?”, you need agreed numbers from several systems. That points to a warehouse (or the warehouse layer of a lakehouse).
If they sound like “What patterns are hiding in our customer messages?” or “Can we predict which machines will fail?”, you need room to explore messy data. That points toward a lake or lakehouse.
2. What kinds of data do you actually hold?
List your sources and mark each: tables from a system (ERP, CRM, finance), files and spreadsheets, documents and text, images, logs, or streams from devices.
Mostly tables? A warehouse covers you. A real mix of tables, text and sensor data? You will need somewhere to land the raw material, which is the lake’s job.
3. Who will use it, and how technical are they?
Managers and finance staff need ready-made, named tables and dashboards. Data scientists need raw access and the freedom to experiment. If both groups are real, plan for both layers, which is where a lakehouse earns its place. If only the first group exists today, do not build for the second yet.
4. How quickly is the answer needed, and how often?
A monthly management pack can tolerate a nightly refresh. A dispatcher or a call-centre lead may need data in minutes. Speed requirements change the design, the cost and the team you need to run it. Name the fastest real need, not the fastest imaginable one.
A simple way to decide
- Mostly structured data, mostly reporting questions, mixed business audience → start with a warehouse.
- Large volumes of varied data, exploration or machine learning is the goal, strong technical team → start with a lake, with rules for naming and ownership from day one.
- Both groups are real and growing, and you can staff the platform → consider a lakehouse, built in layers (raw, cleaned, business-ready).
- Unsure → build the smallest warehouse that answers your first question, and keep the raw copy of every source. That preserves the option to grow into a lake or lakehouse later.
Five mistakes we see repeatedly
- Buying the platform before naming the question. The diagram looks complete, but nobody can say what it is for.
- Calling a pile of files a lake. Without naming rules, ownership and a catalogue, it is a swamp within a year.
- Loading everything. More data does not create more trust. Reconciled data does.
- Skipping definitions. If “sold” means one thing in sales and another in finance, no architecture will fix it. Agree the meaning in writing.
- Ignoring who will run it. A design that needs five specialists is the wrong design for a team of two.
Our experience
In our work with enterprise clients, we have built cloud data foundations that bring records from several operational systems into one place, so reporting comes from a single source.
We can explore with you which of the three approaches fits your questions, starting from one report.
What is the question your business keeps answering by hand?
The right architecture is the smallest one that answers your question
Data warehouses, lakes and lakehouses are tools, not strategies. The organisations that get the most from them start with a specific, painful question, pick the least complicated design that answers it, and add to it as new questions arrive.
If you are comparing architectures and the conversation has become about products rather than questions, that is usually the moment to step back and write the questions down first.
Talk to Balerion about mapping your data and choosing the first release of a platform your teams will trust. Email us at talk@balerion.co.th.
