Spot the errors in this capacity plan for a 200M-vector deployment.

Three things are wrong in the plan, and each is a classic capacity-planning mistake. **Error 1: zero headroom over raw bytes.** The 1.23 TB raw number is the floor, not the budget. HNSW at M=32 adds 200 to 400 bytes per vector of graph adjacency (tens of GB at 200M scale), plus allocator overhead, segment metadata, and free space for ingest. Budget 20 to 30 percent above raw bytes or the system will OOM during normal operation. **Error 2: doubling shards does not halve p99.** HNSW search cost is roughly logarithmic in N, so cutting N in half saves a small fraction of work per shard. Fan-out makes the query wait on the slowest shard, which amplifies the tail. Sharding is for throughput and capacity, not for halving latency. **Error 3: PQ is not lossless.** Product quantization snaps vectors to codebook centroids; the reconstruction is approximate by construction, and recall drops. The standard fix is oversampling followed by rescoring against full-precision vectors, which means keeping originals somewhere (typically on disk). The plan omits that storage line entirely.

**Three errors, each a textbook capacity-planning failure.** - **RAM budget without headroom.** 1.23 TB is just the raw float32 vectors. HNSW at M=32 adds ~300 bytes per vector for the layered adjacency lists, about 60 GB at 200M scale. Allocator and engine overhead is another 10 to 20 percent. Realistic budget is 1.5 to 1.6 TB per replica before HA. A plan that budgets exactly the raw bytes will OOM on the first compaction or ingest spike. - **Sharding latency math.** HNSW search cost scales roughly as O(log N) in the corpus size, so halving N saves only a small fraction of per-shard time. Worse, query latency under sharding is `max(per_shard_latency) + merge_overhead`, and the max over more shards rises in the tail (tail amplification). Net effect: doubling shards typically keeps p99 about the same or slightly worse, not halved. Sharding is for throughput (more queries per second), capacity (corpus too big for one node), and isolation (per-tenant), not for halving latency. - **PQ as lossless.** Product quantization is lossy by construction: it partitions the vector dimensions into subspaces, runs k-means in each, and replaces each subspace's slice with the nearest centroid ID. Reconstruction is approximate. Recall drops, typically by 1 to 5 points at 64x compression depending on dimension and data shape. The standard mitigation is to oversample candidates (top-50 from PQ scoring) and rescore the top-k against full-precision vectors, which requires keeping the originals somewhere (disk in DiskANN-style designs). The plan omits the original-storage line and assumes recall is unchanged, both wrong.