Capacity Planning, and Scaling/Optimization for Vector Workloads
summary
Capacity planning example targets 125 million products with ~2 KB metadata and 1536‑dim vectors. Exact storage hits ~3 TB for vectors (≈7 TB with replicas) and is slow; HNSW needs ~862 GB RAM for graphs (with ~5.5 TB disk after derived source). Enabling derived_source enabled true halves on‑disk copies. Aggressive quantization (binary, 8‑bit, FP16) or disk‑optimized PQ cuts RAM dramatically (example disk‑optimized 32x → ~1.6 TB disk, 44 GB RAM). Recommend ~50 GB shards, ~1.5 vCPU/shard → 54 vCPUs (example i4i.2xlarge — 9 nodes ~$7,000/mo).
AI-written summary · about
chapters (10)
- 0:00Vector workloads in OpenSearch
- 4:35Scaling vector resources
- 7:44OpenSearch vector processing
- 12:07Storage for 125M vectors
- 23:15Reducing storage with derived features
- 28:34Vector compression quantization
- 34:06Disk-optimized vector search
- 38:11Cost, latency, recall trade-offs
- 41:27Capacity planning for shards/CPU
- 45:28Q&A
related talks
39mWhat's in a Vector Database?
34mThe Challenges of Making Vector Search Billion-scale
35mImpact of Vector Search
44mScaling Semantic Search in PostgreSQL
51mVector data in Postgres: Size, TOAST, Filters and Performance
36mWhen Semantic Search Breaks in your RAG systems: RAM Walls, Silent Failures, and the Architecture Decisions
33mTowards a deeper understanding of retrieval and vector databases
25mVector data in Postgres - how's it different from "normal" data?