About StorageMath
Cutting through storage vendor marketing with mathematical truth
StorageMath exists to cut through storage vendor marketing with mathematical truth.
The Problem
Storage vendors make bold claims: “Seven 9s uptime!” “Sub-millisecond latency!” “Survives 4 failures with only 2.74% overhead!”
Some are accurate. Many are misleading. A few are mathematically impossible.
Our Solution
We apply mathematical rigor to every claim. We collect vendor publications, extract quantifiable technical claims, validate with actual mathematics, explain what it means in practice, and compare across all vendors fairly.
Our Principles
Vendor Neutrality
We analyze every vendor with equal scrutiny: VAST, MinIO, Pure Storage, NetApp, AWS, Azure, Google Cloud, Ceph, and more. No favorites. No bias. Just math.
Mathematical Rigor
Every quantifiable claim gets validated: erasure coding calculations, performance analysis, durability mathematics, and cost modeling. If the math doesn’t work, we say so.
Human-Centric Simplicity
Simplicity is our primary metric. A simple solution that works beats a complex solution that’s “optimal” but operationally risky.
Acknowledge Uncertainty
When we don’t have data, we say so. We distinguish between verified facts, reasonable inferences, and speculation. Proprietary systems can’t be fully audited. We acknowledge these limitations.
Real-World Focus
Theory matters, but practice matters more. We consider failure modes, operational complexity, long-term viability, and hidden costs.
Our Methodology
Claim Collection
We gather claims from vendor blog posts, technical whitepapers, marketing materials, conference presentations, and customer case studies. We look for quantifiable claims, performance metrics, durability claims, efficiency claims, and cost claims.
Mathematical Validation
For erasure coding schemes like Reed-Solomon, LRC, and LEC, we calculate actual overhead, validate failure tolerance (theoretical vs practical), and determine rebuild I/O requirements. For performance claims, we validate throughput against node counts and network capabilities. For durability, we verify that “X nines” claims match the underlying mathematics.
# Example: Calculate actual overhead
overhead = (parity_shards / data_shards) * 100
# Validate failure tolerance
theoretical_tolerance = parity_shards
practical_tolerance = calculate_with_locality(...)
Context Analysis
Numbers without context are meaningless. We examine cluster size, network topology, drive types, cache configurations, workload characteristics, and test conditions. We distinguish between synthetic benchmarks and real workloads, peak bursts and sustained throughput.
Trade-off Identification
Every design involves trade-offs. High locality enables fast rebuilds but reduces failure tolerance. Standard Reed-Solomon maximizes failure tolerance but requires higher rebuild I/O. We make these trade-offs explicit.
Real-World Risk Assessment
Beyond theoretical analysis, we consider correlated failures, human error, operational complexity, vendor lock-in, and long-term viability.
Independence
We don’t accept vendor sponsorships, paid reviews, affiliate commissions, or speaking fees from vendors we analyze. Our only bias is toward mathematical accuracy and operational simplicity.
Remember: Question everything. Verify mathematically. Stay honest.