Data warehouse: what it is, when you need one and what it costs to keep

A data warehouse is a database built to answer business questions, not to keep an application running. That's the whole definition, and it explains nearly everything else: why it's different from your ERP, why a mid-sized company can go years without needing one, and why building it badly costs more than not building it at all. This guide covers what management teams actually ask us: what it is, how to tell whether you need one yet, which cheaper alternatives exist and what the maintenance nobody budgets for really costs.

One warning up front: a data warehouse is the right answer to a very specific problem and the wrong answer to plenty of others. We've seen companies spend six figures on a platform and end up exporting to Excel exactly as before, because the problem was never where the data lived — it was that nobody had agreed on what "active customer" meant.

What is a data warehouse and how is it different from your ERP?

Your ERP, your CRM and your e-commerce platform are transactional systems. They're optimised to write lots of small operations very fast: record an order, update stock, register a payment. Their data model is normalised across hundreds of tables, because that's what makes the application quick.

A data warehouse is an analytical system. It's optimised for the opposite: reading millions of rows at once and aggregating them by product, customer, month or sales rep. Its model is deliberately denormalised — fact and dimension tables — so a business question gets answered in one query rather than a fifteen-join puzzle.

Three practical consequences of that difference:

• It keeps history. The ERP usually overwrites current state: if a customer changes price tier, the old tier disappears. The warehouse stores a snapshot of every day, and without those snapshots there's no time series and no demand forecasting worth the name.
• It joins sources. It brings ERP sales together with CRM pipeline and ad spend, which no source system will do for you.
• It leaves operations alone. A heavy query over full history can't be allowed to take down the system your team invoices with every morning.

If your reports still come out of the ERP and nobody complains, you don't need a warehouse yet. Needing one is something you notice, not something you decide in a vendor presentation.

How is it different from a data lake and a lakehouse?

The three names get used interchangeably in sales demos, and they aren't the same thing. The real difference is when structure gets imposed on the data:

| Type | What it stores | Structure applied | Fits when | |---|---|---|---| | Data warehouse | Clean, modelled data | On write | 95% of useful data is tabular: sales, purchasing, stock, payments | | Data lake | Raw files of any format | On read | There are images, audio, logs or very large unmodelled volumes | | Lakehouse | Raw files with a table layer on top | Mixed | You want both and have someone to maintain it | | Data mart | A slice of the warehouse for one area | On write | Finance or sales need their own view without touching the rest |

For the vast majority of mid-sized companies, the data that drives decisions is tabular and fits comfortably in a conventional warehouse. A data lake earns its place when unstructured data enters the picture — documents, quality inspection images, recordings — or when volume makes modelling everything up front unworkable. If someone proposes a lakehouse for 40 GB of invoices, they're selling architecture, not solving your problem.

When does a mid-sized company actually need a data warehouse?

These are the six signals we use. You don't need all six; three makes it a serious conversation.

• You join sources by hand every month. Someone exports from the ERP, exports from the CRM, pastes it into a sheet and joins with a VLOOKUP. If that happens monthly, you already have a data warehouse: it lives on a laptop and has no backup.
• You need history the system doesn't keep. You want to know how many customers were on the premium tier last March and there's no way to reconstruct it.
• Heavy queries slow the business down. The quarterly report has to run overnight because during the day it makes the ERP unusable.
• Two departments report different numbers for the same thing. The classic symptom. Careful, though: technology almost never fixes this. It gets fixed by defining metrics and giving them an owner, which is data governance. The warehouse is where the agreed definition lives in one place — it doesn't invent the definition for you.
• Every new report takes weeks. Because each one starts from scratch against source systems instead of from tables that are already prepared.
• You want models in production. A forecasting or scoring model needs data in the same shape every day. Without a stable layer underneath, what you have is a prototype running on someone's laptop. The full story is in data engineering.

And the reverse signal, just as important: if all the relevant information lives in a single system, native reports cover your questions and nobody spends hours assembling spreadsheets, you don't need one. Building it "to be ready" is the most common way to pay three years of maintenance for something nobody queries.

Which cheaper alternatives are worth trying first?

There's almost always an intermediate step that solves 80% of the pain for a fraction of the cost. From lightest to heaviest:

| Alternative | What it solves | Where it breaks | |---|---|---| | Native ERP/CRM reports | Single-system questions | As soon as two sources must be joined | | Read replica of the ERP | Heavy queries without touching production | No history, no cross-source joins | | Small database with two or three loads | Sales + CRM joins, basic history | Grown without a model or tests, it becomes a swamp | | BI tool with its own model | Fast dashboards for one department | The logic gets trapped inside the product | | Full data warehouse | Cross-department source of truth, history, models | Demands maintenance and someone accountable for it |

The small database with scheduled loads is the most underrated option. A managed cloud warehouse, three nightly load processes and a five-table model cover what most management committees need, and infrastructure cost at mid-sized volumes runs to tens of euros a month, not thousands. Storage is never the expensive part: agreeing definitions, building the loads and keeping them alive is.

If what you mainly want is visualisation, start there rather than with a platform — the selection criteria are in business intelligence tools.

What does it cost to build and, more to the point, to maintain?

Three line items. The third is the one that sinks projects, because it never appears in the original proposal.

Build. Ingesting source systems, the analytical model and the first serving tables for one bounded domain — usually sales: weeks of work, not months, if scope is closed. When the proposal is "integrate everything", the project gets measured in quarters and the risk multiplies.

Infrastructure. Storage and compute. At mid-sized volumes this is usually the smallest item and the one that scares people most, out of unfamiliarity. Spend explodes because of badly written queries and needless full reloads, not because of data size.

Maintenance. This is where the real money goes. The ERP gets updated and a field changes. The business opens a new line. A subsidiary shows up with its own customer master. Someone asks for a metric that forces a model change. As a working rule, budget roughly 15–25% of the build cost every year just to keep what it reports true. A warehouse without maintenance doesn't break all at once: it degrades until people go back to trusting their own spreadsheet. The full budgeting logic is in what an AI project costs.

And one question we put to every supplier, ourselves included: when you're finished, who can touch this without you? If the answer implies permanent dependency, the real price isn't the one in the quote.

How do you build it without opening a year-long project?

The sequence that works — and the order matters more than the tooling:

1. Pick a decision, not a system. "Know the margin by product line every Monday" is a scope. "Integrate the ERP" is not. 2. Agree definitions before touching anything. What counts as a valid order, how returns and credit notes are treated, which date wins. Written down and signed off by whoever answers for the number. 3. Build the raw layer first. A copy of the source exactly as it arrived, with a load date. That's what lets you recalculate the past when you find a definition error, and it takes far less space than people fear. 4. Model only what that decision needs. One fact table, three or four dimensions. Resisting the urge to model the whole business is half the work. 5. Put transformations in versioned code. If the logic lives in clicks inside a tool, switching tools costs double and finding out what someone changed on Tuesday is impossible. 6. Add three tests and one alert. Key uniqueness, amount range and freshness. The alert goes to a channel someone actually reads. 7. Connect the dashboard last and switch off the manual report. If the old process is still alive, you haven't finished: you've added work. How to design that dashboard is in the executive dashboard guide.

Six to eight weeks puts one domain into production. The most valuable outcome usually isn't the result but what you learn along the way about the real state of your systems, which almost never matches the official inventory.

Frequently asked questions

Cloud data warehouse or on-premise?

For most mid-sized companies, cloud. Upfront cost is zero, growth is elastic and you don't have to size hardware blind. On-premise earns its place when there are legal requirements on data location, or when infrastructure is already paid off and a team already runs it.

Do I need a data warehouse to do BI?

Not always. For dashboards over a single system, a BI tool connected directly can be enough. The warehouse becomes necessary when you have to join sources, retain history or give several departments the same number. The difference between the two layers is covered in what business intelligence is.

How long until it pays off?

The immediate return is recovered time: the hours someone spent assembling reports by hand, measurable in the first or second week after the switch. The return from better decisions takes longer and is harder to attribute, but the first alone usually covers building one domain.

What if my data is dirty?

That's the normal situation, not the exception. The warehouse doesn't clean anything by itself: it makes the mess visible, which is already progress. Cleaning is tackled by priority — the fields feeding the chosen decision first — and sustained with automated rules on every load, not with one heroic clean-up. Where to start is covered in data strategy.

If you recognised three or four of the signals above, the next step isn't asking for platform quotes: it's narrowing down one concrete decision and seeing what's missing to feed it. That's exactly what we do in the audit — two weeks, real systems, a map of what's there and what isn't — and if you'd rather talk it through first with no strings attached, let's talk.