What a data warehouse is for
A data warehouse is a modelled, governed store of analytical data where definitions are enforced rather than negotiated per report. Its value is not storage — cloud storage is cheap and your source systems already hold the data. Its value is that everyone querying it gets the same answer to the same question.
That reframing changes what a good implementation looks like. A warehouse loaded with faithfully replicated source tables and no agreed model is a slower copy of the systems you already had.
Warehouse, lake or lakehouse?
| Warehouse | Lake | Lakehouse |
|---|
| Structure | Modelled, enforced on write | Raw files, meaning on read | Tables and transactions over lake storage |
| Best for | Finance and operational reporting | Unstructured and exploratory data science | Mixed analytics and ML at scale |
| Main risk | Rigid if modelled too narrowly | Becomes a swamp without governance | Complexity beyond what a small team can run |
For the reporting and planning workloads most finance functions need, the warehouse pattern remains the right fit — because the value comes from enforced definitions, which is precisely what the lake pattern defers.
The semantic layer matters more than the platform
Once more than one tool or team consumes the warehouse, metric logic gets re-implemented by each of them. Within a year the same metric name carries different values in different reports, and reconciling them becomes somebody's standing job. The semantic layer is where a definition is written once and enforced everywhere.
Platform choice is largely reversible. The data model and the semantic layer are not — they are what a decade of reports get built on.
Controlling the cost
- Compute, not storage, is the bill. It is driven by query and refresh patterns, not by how much data you hold.
- Idle warehouses left running are the most common single source of waste.
- Refresh cadence should match reading cadence. Hourly refreshes on a report reviewed weekly is pure spend.
- Incremental over full reload wherever the source supports it.
- Monitor per-workload cost from day one, so attribution is possible before the bill becomes a problem.
How we build it
- Model the first subject area properly. Usually finance — dimensional model, conformed dimensions, grain agreed and documented.
- Build the semantic layer alongside it, not after the first three dashboards have already invented their own logic.
- Reconcile to the ledger continuously as a monitored control.
- Instrument cost and quality from the first load.
- Extend subject area by subject area, each one in production before the next begins.
Data warehousing FAQs
Warehouse, lake or lakehouse?
Warehouse for finance and operational reporting, where enforced definitions are the value. Lake for unstructured exploration; lakehouse where both are needed at scale.
Which platform should we choose?
The majors are close on capability. Decide on existing team skills, cloud commitments and how pricing behaves under your query pattern — the data model matters more than the platform.
What does it cost to run?
Compute dominates, driven by query and refresh patterns. Idle warehouses and over-frequent refreshes cause most overspend; control is a build-time design decision.
Do we need a semantic layer?
If more than one tool or team consumes the warehouse, yes — otherwise each re-implements metric logic and definitions diverge within a year.
How long does implementation take?
10–16 weeks for the first subject area in production; subsequent areas are much faster.
Where this fits
Warehousing follows data strategy and integration, and enables custom analytics and predictive analytics.
