# Pod capacity planning
## The levers
- **Pod type** (p1, p2, s1...): memory and compute per pod. Bigger types hold more vectors and answer faster.
- **Replicas**: copies of each shard. More replicas, more query throughput.
- **Shards**: partitions of the data. More shards, more total capacity.
## Steps
1. **Measure first.** Index a representative slice and load-test: find the QPS where latency breaches your SLO on one replica.
2. **Size replicas** from peak QPS divided by per-replica sustainable QPS, plus headroom (N+1 at least for production).
3. **Size shards and pod type** from total vector count and dimension: the data must fit in the pods' memory with room to grow.
4. **Start small, scale up.** It is cheaper to add replicas than to run oversized pods for a quarter. Serverless first for unknown traffic; pods when the traffic shape is known and steady.
5. **Revisit quarterly.** Data grows; QPS patterns change. A yearly-old sizing is a guess.
## Traps
1. Sizing from marketing QPS instead of measured: the most expensive mistake in this list.
2. One giant pod instead of sharded smaller ones: worse failure blast radius and harder scaling.
3. Forgetting replicas do not help write-heavy bursts the way they help reads: size the write path separately.
4. Leaving a scaled-up pod fleet after the traffic spike: pod-hours accrue silently. Scale down deliberately.