A data warehouse for small teams

Most teams know this matters. Fewer have decided who owns it. Most advice about a data warehouse assumes a team that does not exist at your size. Here is the version that does not.

Numbers get quoted in meetings long after anyone remembers how they were calculated. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

What to keep

Reporting queries and application queries want different shapes. That sounds obvious written down. It is still the thing most often skipped. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. The cost of getting this wrong is rarely visible on the day it happens.

What good looks like

Start with the questions, not with the schema. The teams that handle this well are rarely the ones with the biggest budgets. Write the reasoning down alongside the decision, because the reasoning is what changes first.

In practice

Data outlives the applications built on top of it, which is why the model deserves more thought than the screens. Three things worth confirming about a data warehouse before you move on:

• Someone can say what the current setup is without going to look
• Reporting queries and application queries want different shapes — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If any of that sounds like a description of your current setup, it is fixable.