For most mid-sized companies asking whether they need a data warehouse, the answer is not yet. That is not a stalling answer. The question almost always arrives attached to a specific irritation: a report that takes four minutes to run, a number that has to be assembled by hand from three systems, a month-end spreadsheet somebody rebuilds because last month's version is gone. Each of those has a cause, and in most cases the cause is cheaper to address directly than by standing up an analytics platform and the pipelines that feed it. This page is about telling the difference.
None of this is an argument against warehouses. There is a point at which one becomes clearly correct, and companies that reach it and keep improvising pay for that too. The point is that the decision is usually made in the wrong order: the platform gets chosen first, and the problem it was meant to solve gets described afterwards, at which time it turns out to have been three different problems.
The three problems hiding behind the question
Nearly every conversation that starts with data warehouse turns out to be one of three complaints. They feel similar from the outside because they all show up as reporting pain, but they have almost nothing in common technically, and they have different cheapest fixes.
Reporting is slowing the production system
Someone runs a heavy query against the same database that takes orders, and order entry gets slow. Operations notices before finance does. The instinct is to move analytics somewhere else entirely, and that instinct is right, but somewhere else can be a read replica of the same database rather than a different technology. A replica gives analysts a copy they cannot slow down or lock, needs no new data model, no transformation logic, and no ongoing mapping work, and is typically a configuration exercise rather than a project. The reports keep working because the schema is identical.
The answer spans several systems
Revenue lives in the accounting system, the work lives in the operational system, and the customer record lives in the CRM. Answering a straightforward question means exporting three times and joining in a spreadsheet. This is the case people most often generalise into a warehouse, and sometimes it should be. But if the question is stable and the volumes are moderate, a scheduled extract of the relevant tables into a single reporting database will answer it. You are still building a join and still agreeing what a customer is. You are simply not also buying a platform, an orchestration layer, and a modelling convention to do it.
The history you need has been overwritten
This is the one people describe least accurately. The complaint sounds like we cannot report on trends, but the underlying fact is that the source system stores current state only. A record has a status field, the status changes, and the previous value is gone. No reporting tool recovers information the application never kept. The fix belongs in the application: record the transition as an event when it happens, with a timestamp and an actor. That is usually a small change in one place, and it is worth making regardless of what you later do with analytics, because it is also the audit trail you will eventually be asked for.
What people buy versus what usually solves it
| Problem you have | What people buy | What usually solves it | When the warehouse is right |
|---|---|---|---|
| Reports slow down the production system | A warehouse plus a BI tool | A read replica, with reporting pointed at the replica | When replica lag or query shape stops being acceptable, or when several sources must be joined |
| Numbers must be combined from several systems | A warehouse and an ingestion tool per source | A scheduled extract of the needed tables into one reporting database | When three or more sources are involved and the questions keep changing |
| Trend and point-in-time history is missing | A warehouse, on the assumption it creates history | Event or status-change history recorded in the application itself | When history is needed across systems, or must be retained beyond the source system's life |
| Analysts wait on IT for every extract | Self-service BI on top of a new platform | A governed set of reporting views the analysts can query directly | When ad-hoc extract demand is continuous and views no longer keep up |
| Queries are too slow even on a copy | More compute on the transactional database | Indexing, summary tables, or a nightly aggregate | When volume or query complexity makes direct querying impractical at any tuning level |
The triggers that genuinely justify one
There are conditions under which the smaller fixes stop being cheaper, and continuing to improvise costs more than building the thing properly. They are recognisable, and they tend to arrive together.
- Several systems must be analysed together on a recurring basis, and the joins between them are now business logic rather than a one-off question.
- Point-in-time history is a real requirement. You need to know what the pipeline looked like on the last day of a quarter, not what it looks like now.
- Analyst demand outstrips ad-hoc extracts. When people are waiting days for data, or building their own shadow extracts, the queue itself has become the cost.
- Volumes or query complexity make direct querying impractical, even against a replica, even after tuning.
- Source systems are being retired and their data has to outlive them for reporting or compliance reasons.
- The same metric is being recalculated in several places, and the versions disagree often enough that meetings now start by reconciling them.
One trigger on its own is usually not enough. Two or three together, in a business that is not going to get simpler, is a reasonable point to start. The useful test is whether you are still solving one question or have started maintaining an unofficial reporting system out of extracts and spreadsheets, because at that point you already have a warehouse, just an undocumented one with no owner.
The costs nobody budgets
Warehouse business cases are usually built around storage and compute, because those are the numbers that are easy to look up. They are also the smallest line. The work is the pipelines, and pipelines are not a one-time build.
Every source is its own project
Each system you pull from needs an extraction method, a mapping from its fields to your model, decisions about incremental versus full loads, handling for deletes, and rules for what happens when a load fails halfway. A system with a documented API and stable identifiers might be a couple of weeks. One where records are soft-deleted inconsistently and the primary key was reused after a migration in 2014 will take considerably longer, and the difficulty is not visible until you are inside it.
Upstream schema changes become your problem
Once you depend on a source system's structure, every change to that structure is a change to your pipeline. Vendors add columns, rename fields, and change enumerations in routine releases without telling you, because from their perspective nothing broke. You find out when a load fails, or worse, when it succeeds with wrong values. Budget for someone to own this permanently, and put monitoring on load success and row counts from the first day rather than the first incident.
The ongoing shape of the cost
Plan for the warehouse to need continuous attention proportional to the number of sources it touches, not to the amount of data it holds. Two sources is manageable by an existing team alongside other work. Eight sources is a role. That relationship is the single most useful thing to know before committing, and it is the one most often left out of the plan.
The failure mode: a warehouse nobody trusts
The most common bad outcome is not a warehouse that fails to load. It is one that loads perfectly, on schedule, and gets used by nobody, because the first time someone compared its revenue figure to the accounting system's revenue figure they were different, and no one could say which was correct. After that, every meeting goes back to the old spreadsheet.
The cause is almost always that the definitions were never agreed before the modelling started. Whether revenue is recognised at invoice or at completion, whether a cancelled order counts toward bookings, whether an active customer means transacted in twelve months or has an open contract. These are business decisions, not technical ones, and a data team will make them by default if nobody makes them deliberately. Once a warehouse has produced one number a finance lead disputes, its credibility is difficult to recover.
How to decide
- 1
Write down the specific questions you cannot answer today, with the decisions each one would change. Vague questions produce vague architecture.
- 2
For each question, identify which of the three problems it is: contention on the production system, data spread across systems, or missing history.
- 3
Apply the smallest fix that resolves it: a read replica, a scheduled extract into a reporting database, or event history added in the application.
- 4
Count how many of the genuine triggers you meet. Two or more, with sources that are not going to consolidate, is a reasonable point to build.
- 5
Before choosing anything, agree the definitions of your top metrics with named owners and confirm the numbers reconcile to the systems of record.
- 6
If you do proceed, start with one source and one reported outcome in production, then add sources one at a time. A warehouse built all at once is a warehouse tested all at once.
Following that order means the worst case is you spend a few weeks fixing reporting properly and defer a larger decision with better information. The alternative worst case is a platform, a set of pipelines, and a maintenance obligation attached to a problem you had not finished describing.
Common questions
- Is a read replica really enough for reporting?
- For a large share of cases, yes. A replica removes the contention that makes reporting hurt the production system, and existing queries keep working because the schema is unchanged. Its limits are that it holds one system's data, it holds current state only, and it can lag behind the primary by seconds or minutes. If any of those three limits is the actual problem, a replica will not fix it.
- What is the difference between a reporting database and a warehouse?
- A reporting database is typically a copy of one or two sources, kept in roughly their original shape, refreshed on a schedule. A warehouse holds data from many sources restructured into a common model, usually with history retained. The practical difference is the transformation and modelling layer, which is where most of the effort and nearly all of the ongoing maintenance lives.
- Can we start small and grow into a warehouse later?
- Yes, and it is usually the better sequence. Extracts into a single reporting database teach you which joins matter, which definitions are contested, and which sources are difficult, all of which you would otherwise discover mid-build. That knowledge transfers directly into a warehouse design if you later need one.
- How long does building a warehouse take?
- Time scales with the number and quality of sources rather than the volume of data. A single well-documented source with agreed metric definitions can be productive in weeks. Several legacy sources with inconsistent identifiers and contested definitions run into months, and the definitional work is often the longer half.
- Do we need a warehouse before we can use AI or machine learning on our data?
- Not necessarily, and starting with one delays the part that determines whether the idea works. Most first useful applications need a specific, well-labelled slice of data rather than everything in one place. Prove the use case against an extract, and let the results tell you whether centralising the underlying data is worth it.
- Our reports already disagree with each other. Will a warehouse fix that?
- Only if you fix the definitions first. Reports disagree because the same metric is calculated differently in different places, which is a governance problem rather than a storage one. Loading conflicting logic into one platform produces a single authoritative-looking number that is still wrong, and it is harder to challenge because it now looks official.