Sizing decides the total cost of a data platform for the five years that follow, and it is rarely settled when people think it is. An undersized cluster costs an emergency migration; an oversized one freezes budget that produces nothing. I cost the balance point from your real workload.
What the plan covers
Current measured load: IO profiles, seasonality, real peaks rather than misleading averages. Growth projections by scenario over 3 and 5 years. The full cost of each option: hardware, cloud, replication, networking, operations. The trigger thresholds that say when to add nodes, and at what cost.
The method
Production measurements first, benchmarks next: warp-style throughput tests for object storage, network profiling, existing operations metrics. Every growth assumption is confronted with your real history. The result translates into a concrete purchase decision: public cloud instance types, a managed PaaS offer, or a Dell or HPE OEM catalog configuration. The deliverable is a costed plan with explicit trade-offs, not a vendor price list.
This is neither generic consulting nor staff augmentation: it is the costing that precedes a hardware or cloud commitment.
FAQ
Why not trust vendor sizing recommendations?
Vendor recommendations describe a configuration that works, not the cheapest one that works for your workload. An independent sizing plan starts from your real measurements and targets the smallest system that holds your peaks with the intended margin, which often changes the budget by a third.
When should a sizing study be redone?
Before every multi-year commitment: hardware purchase, cloud contract renewal, migration or redesign. And as soon as usage drifts from the planned scenario, typically when measured growth exceeds the projection by more than a third, before latency starts degrading applications.