qdrant-sizing

# Sizing a Qdrant Deployment Sizing is not `points × dims × 4`. Raw vectors are only one part of the footprint. Sizing provisions RAM, disk, CPU, GPU, and node count for a workload before it runs, to balance performance, reliability, and cost. Each resource is driven by different requirements: - RAM and disk: number of vectors, vector dimensions, payload size, throughput, target query latency, and search quality requirements. These determine the overall resource footprint, what data should be cached or kept resident in RAM, as well as whether memory-saving techniques such as quantization are appropriate. - CPU cores: peak query and ingest rates, target p95/p99 latency, and indexing/optimization workload - GPU (if using GPU-accelerated indexing): indexing workload and required indexing time - Node count: fault-tolerance and availability requirements, plus throughput and capacity requirements that cannot be met by a single node Before sizing, collect these workload requirements and state explicit assumptions for any that are unknown. Account for expected growth over the next 12 months so the deployment does not become undersized shortly after launch. ## Sizing RAM and Disk Use when: someone asks how much RAM or disk they need, how much data should be kept in RAM, how to size memory for a given workload, or how much capacity they will need as their data grows. ### Estimate the data footprint Memory requirements mainly come from Qdrant's data structures, with additional me...