A company is building a new analytics platform. Moderate data volume, heavy BI usage, strong governance requirements, a small data team. Warehouse or lakehouse?
Show the full answer Hide the answer
What is being tested
Whether you match the architecture to the workload and the team, rather than to what is architecturally fashionable.
The reasoning
Every characteristic given points at a warehouse:
- Moderate volume means the storage-cost argument for object storage — the strongest argument for a lakehouse — does not apply. That argument only becomes decisive at scale.
- Heavy BI is precisely what warehouses are optimised for: query performance, concurrency, mature semantic layers, and tooling that analysts already use.
- Strong governance favours the maturity of warehouse access control, column-level security, auditing and lineage tooling.
- A small team is the decisive factor. A lakehouse imposes ongoing operational work that a managed warehouse hides: compaction of small files, clustering, metadata management, table format version upgrades, and engine compatibility. That is a real, permanent staffing cost.
When a lakehouse is right
The conditions are specific and worth being able to state:
- Very large volumes where object storage economics dominate the decision.
- Machine learning workloads that need direct file access from training frameworks rather than through a SQL interface.
- Semi-structured and unstructured data alongside tabular data.
- Multiple query engines over one copy of the data.
- Continuous ingest with continuous correction, which is the pressure that produced Uber's incremental table format work — trips whose fares adjust, ratings that arrive late, disputes that change records days afterwards. Full-partition rewrites could not keep up with either the volume or the freshness requirement, and the answer was incremental upserts plus the ability for consumers to ask "what changed since I last looked".
None of those conditions appear in the question.
Why "both" is the wrong answer here
It is a legitimate architecture at scale and the wrong recommendation for a small team, because it means operating two platforms and a synchronisation path between them. Recommending it here doubles the operational surface for a workload that one platform serves well.
Why federation is wrong
Querying operational databases directly puts analytical load on transactional systems — long-running scans holding connections while the application times out — and provides no history. It is the failure mode that warehouses exist to prevent.
What a strong answer adds
Naming the revisit condition. "Start with a managed warehouse. Revisit when volume makes storage cost material, when machine learning workloads need file-level access, or when we have a data platform team that can own compaction and table maintenance." That converts a decision into a decision with an exit, which is what makes it defensible in two years.