Does your SME need a data warehouse, or better-kept Excel?
The right question is not "do we need a data warehouse?". It is "which decision or reliability problem would a warehouse solve better than a clean shared workbook?".
· 9 min read
Many founders hear about data warehouses the moment Excel starts to crack: files flying by email, conflicting versions, a meeting where everyone brings a different number. The reflex is to buy a platform. That is not always the right first move.
Direct answer: an SME needs a data warehouse when several sources must produce the same indicators every week for several people, with a stable history and a single calculation rule. Otherwise, better-kept Excel (or a Power Query model), versioned and stored in one shared place, is often enough and cheaper to run.
This piece follows the data audit article: it does not redo the diagnosis. It sets decision criteria. It is for founders and operators in SMEs (roughly 20 to 250 people) who still steer a lot with spreadsheets, not for data teams in mid-market firms that already have a stack.
Stable definitions (so everyone means the same thing)
Better-kept Excel here is not "one more file". It is a workbook (or a small set) with a clear source, a written calculation rule, a named owner, a single shared location (for example team SharePoint or OneDrive), and a known refresh cadence. Power Query fits when it reloads files or exports without manual copy-paste.
A data warehouse is central analytical storage: data from several systems (ERP, CRM, finance, files) is loaded, cleaned, and organized for analysis and reporting. It is not the operational system where orders are typed. It is not a folder of CSV files either.
Power BI, Looker Studio, or another visualization tool does not replace a warehouse. They consume data. If upstream data stays inconsistent, the dashboard only displays the disagreement more nicely.
Five signals that better-kept Excel is still enough
You have one to three main sources (for example ERP + a bank export + a sales tracker), and Monday decisions mostly rely on those.
Only one or two people update reporting, and they can explain every formula. The file stays within a reasonable Excel size without regular crashes.
You do not need a long frozen history month by month: a rolling view or a manually archived monthly export still works.
Number disagreements mostly come from multiple versions or forgotten filters, not from a structural inability to join systems.
In that case the useful work is often: one master file, Power Query for imports, clear sheet names, protected calculation ranges, and a short note on "where this number comes from". Less flashy than a warehouse. Often a better return.
Five signals that a warehouse (or analytical database) is becoming relevant
Four or more sources must be joined every week, with different keys (customer, SKU, warehouse) that never match on the first try.
Several teams read the same KPIs (leadership, sales, finance, ops) and each "fixes" the file on their own. Truth dilutes.
You need a stable history (stock, margin, pipeline) to compare periods without rewriting the past on every export.
Reporting must stay fresh (daily or intra-day) without one person spending a morning pasting CSVs.
Business rules (order status, margin, average basket) change and must apply to everyone at once. A warehouse, or at least a shared analytical database fed by a simple pipeline, then becomes the single reference. The exact tool (cloud warehouse, SQL database, light lakehouse) matters less than that reference.
A one-page decision grid
Ask four questions. Count the yeses.
1) How many distinct systems must be joined for leadership reporting? If the answer stays above three, lean toward a central layer.
2) How many people must read the same number without opening a colleague's file? Beyond three regular readers, a shared model or warehouse cuts copies.
3) Do you need to compare this April to last April under the same rules? If yes, historizing in a spreadsheet gets fragile.
4) Has a copy-paste error already driven a visible bad decision (stock, margin, cash) in the last six months? If yes, automate loading before buying more charts.
Zero to one yes: tighten Excel / Power Query. Two yeses: shared model + light automation, reassess in six months. Three or four yeses: design a small central analytical layer (warehouse or equivalent) before stacking more dashboards.
What a warehouse will not fix
Different customer codes across tools. Order statuses invented in each team. A half-empty CRM. A warehouse copies that debt. It does not dissolve it.
That is why a useful data audit starts with definitions and flows, not with picking a cloud vendor. Without a data owner and a written rule, you get an expensive warehouse that still produces three truths.
Conversely, "staying on Excel" is not a strategy if nobody will own the master file. The topic is not Excel versus the cloud. It is one operational truth, at the right complexity level.
Decide without picking the wrong floor
For most SMEs the healthy sequence is: clarify indicators and sources, harden shared reporting (often Excel / Power Query, sometimes a BI tool on clean exports), then, only if the signals above pile up, invest in a warehouse or analytical database.
If you still hesitate, do not start with a platform RFP. Take two real decisions from last week and trace the data used. The right technical floor shows up quickly.
Want a clear call between master file and central layer?
We look at your sources, KPIs, and real friction, then tell you plainly whether better-kept Excel is enough or whether you need an analytical base.