Vector database capacity planning fails in predictable ways. Teams estimate storage based on vector count alone and discover at 60% capacity that memory consumption is growing faster than disk because the index structure consumes RAM at a rate they did not model. Or they provision compute for average query load and get paged at 3 AM when a batch ingestion job competes with a traffic spike and query latency doubles. Or they plan for twelve months of growth and hit the wall at six months because their document ingestion rate exceeded projections by a factor of three.
Capacity planning for vector databases is different from capacity planning for traditional databases. Traditional databases store structured data with predictable row sizes and well-understood indexing overhead. Vector databases store high-dimensional vectors with index structures that have non-linear memory and compute scaling properties. The planning model must account for these properties or it will produce estimates that are wrong in the dangerous direction — optimistic.
This framework covers the three dimensions of vector database capacity: storage, memory, and compute. For each dimension, it provides the calculation method, the variables that affect it, and the headroom recommendations based on production experience.
Prerequisites
You need the following inputs before starting the calculations.
Vector specifications. The dimensionality of your vectors (384, 768, 1536, etc.), the data type (float32, float16, binary), and the expected vector count at your planning horizon. If your vector count is growing, calculate the count at three, six, and twelve months.
Metadata specifications. What metadata fields are stored alongside each vector, their data types, and their sizes. Metadata storage is often the forgotten component of capacity planning. A vector with 1536 float32 dimensions takes 6 KB. If each vector also stores a 2 KB text chunk, a 500-byte JSON metadata object, and a 100-byte ID, the per-record storage is closer to 9 KB — 50% larger than the vector alone.
Query characteristics. Queries per second at peak and average, the number of nearest neighbors requested per query (k), and whether queries include metadata filters. Filter queries can be significantly more expensive than pure vector similarity queries, depending on the database’s filter implementation.
Index configuration. The index type (HNSW, IVF, etc.) and its parameters (M and ef_construction for HNSW, nlist and nprobe for IVF). These parameters directly determine memory consumption and query latency.
Storage capacity planning
Raw vector storage
Calculate raw vector storage as: vector count multiplied by dimensionality multiplied by bytes per dimension.
For float32 vectors at 1536 dimensions: 1,000,000 vectors x 1536 dimensions x 4 bytes = 6.14 GB of raw vector data.
For float16 vectors at the same dimensionality: 1,000,000 x 1536 x 2 = 3.07 GB. Using float16 halves storage with minimal impact on retrieval quality for most embedding models.
For binary vectors at 1536 dimensions: 1,000,000 x 1536 / 8 = 192 MB. Binary vectors are extremely compact but only suitable for binary embedding models.
Index storage
The index structure adds storage overhead on top of the raw vectors. The overhead varies by index type.
HNSW index overhead: typically 1.5x to 2.5x the raw vector storage. The overhead comes from the graph structure that connects vectors across multiple layers. Higher M values (more connections per node) increase both search quality and storage overhead. A 6 GB raw vector dataset with HNSW (M=16) needs approximately 12-15 GB of index storage.
IVF index overhead: typically 1.1x to 1.5x the raw vector storage. IVF stores cluster centroids and inverted lists, which add less structural overhead than HNSW graphs. The tradeoff is lower recall at the same query latency.
Quantized index storage: if the index uses product quantization or scalar quantization, the quantized vectors replace the full-precision vectors in the index. Product quantization with 64-byte codes reduces vector storage from 6 KB to 64 bytes per vector — a 94% reduction. The full-precision vectors may still be stored separately for re-ranking.
Metadata storage
Calculate metadata storage separately. If each record stores 1 KB of metadata and you have 10 million records, that is 10 GB of metadata. Metadata is typically stored in a row-oriented format, so the actual storage may be higher due to indexing overhead on filterable fields.
Index every metadata field that appears in your filter queries. Index storage for metadata fields varies but budget 20-50% additional storage for metadata indexes.
Total storage calculation
Total storage = (Raw vector storage x Index overhead multiplier) + Metadata storage + Metadata index storage + Write-ahead log + Snapshots
Add 20% for write-ahead logs and snapshot overhead. Add another 20% as headroom for unexpected growth.
For a 10 million vector system at 1536 float32 dimensions with HNSW and 1 KB metadata per record:
- Raw vectors: 61.4 GB
- HNSW index (2x): 122.8 GB
- Metadata: 10 GB
- Metadata indexes: 3 GB
- WAL and snapshots: 27 GB
- Headroom (20%): 44.6 GB
- Total: ~268 GB
Memory capacity planning
Memory is the most critical dimension for vector databases because retrieval latency depends on how much of the index fits in RAM.
Index memory requirements
HNSW: the entire graph structure must be in memory for fast traversal. Budget the full HNSW index size as the minimum memory requirement. For the 10 million vector example above, that is 122.8 GB of memory for the index alone.
IVF with PQ: only the cluster centroids and the quantized vectors need to be in memory. The full-precision vectors can reside on disk and be loaded on demand for re-ranking. This is the primary advantage of IVF+PQ for large datasets — memory requirements scale with the number of centroids and the quantization code size, not the full vector size.
Working memory
Beyond the index, the database needs working memory for query processing: result buffers, distance computation, filter evaluation, and connection handling. Budget 10-20% of index memory for working memory.
Memory planning by scale
For datasets under 10 million vectors at 1536 dimensions: provision enough memory for the full HNSW index. This gives you the best query latency and recall.
For datasets between 10 million and 100 million vectors: consider IVF+PQ with the quantized index in memory and full vectors on SSD. Accept the recall tradeoff (typically 90-95% vs. 98%+ for full HNSW) for the memory savings.
For datasets above 100 million vectors: you need a distributed setup with sharding. Each shard holds a portion of the index. Memory requirements per shard depend on the shard size and the index type. Plan memory per shard using the same calculation as above.
Compute capacity planning
Query throughput
Queries per second depends on the index type, the dataset size, the number of neighbors requested, and the query complexity (with or without filters).
HNSW query cost: scales logarithmically with dataset size. Doubling the dataset size increases query latency by a small constant factor. The primary compute cost is the graph traversal, which visits a bounded number of nodes regardless of dataset size.
IVF query cost: scales linearly with the number of clusters searched (nprobe). Higher nprobe means more clusters to search, which means more distance computations. The relationship between nprobe and latency is approximately linear.
Filter query cost: depends on the filter implementation. Post-filtering is cheap but can return fewer results than requested. Pre-filtering requires scanning the filtered subset before or during vector search, which adds latency proportional to the filter selectivity.
Compute planning formula
Start with a benchmark on your actual data. Run queries at increasing throughput and measure p95 latency. Find the throughput at which p95 latency exceeds your SLA. That is your single-node capacity.
For the 10 million vector HNSW example: a single modern server (64 cores, 256 GB RAM) typically handles 500-2,000 queries per second at p95 latency under 50ms for pure vector search. Filter queries reduce this by 20-60% depending on filter selectivity.
Plan for peak load at 70% of capacity. This gives you headroom for traffic spikes and background operations (index rebuilding, compaction, ingestion).
Ingestion compute
Ingestion competes with query processing for compute resources. Plan ingestion capacity separately.
Bulk ingestion (loading millions of vectors) requires significant compute for index building. Budget dedicated compute windows for bulk operations. During bulk ingestion, query latency may increase by 50-200%.
Incremental ingestion (adding vectors one at a time or in small batches) has lower compute impact but degrades index quality over time. Schedule periodic index rebuilding to maintain query performance. The rebuild frequency depends on your ingestion rate — a common pattern is nightly rebuild for systems with heavy daytime ingestion.
Growth planning
Capacity planning is not a one-time exercise. Build a growth model that projects capacity needs over time.
Vector count growth. Track the rate of vector count increase. If your corpus grows by 1 million vectors per month, project when you will hit your current capacity ceiling. Plan expansion (adding nodes, upgrading hardware, or migrating to a larger tier) before you hit the ceiling, not after.
Query volume growth. Track query volume trends. Seasonal patterns, product launches, and user growth all affect query volume. Model your peak query volume at 2-3x your average, not 1.2x.
Metadata growth. Metadata per vector tends to grow over time as applications add fields. A vector that stores 500 bytes of metadata today may store 2 KB in six months. Factor metadata growth into storage planning.
This diagram requires JavaScript.
Enable JavaScript in your browser to use this feature.
Common failure modes
Planning for average load. Capacity must handle peak load, not average load. A system that handles 1,000 QPS comfortably will collapse at 3,000 QPS. If your peak-to-average ratio is 3x, plan for 3x.
Ignoring memory fragmentation. Long-running vector databases accumulate memory fragmentation. Plan for 10-20% memory overhead beyond the calculated requirement. Monitor actual memory usage and compare it against the calculated requirement — if actual usage exceeds calculated by more than 20%, investigate fragmentation.
Not testing at planned scale. Calculations are estimates. Before committing to a capacity plan, test at the planned scale. Load the target number of vectors, run queries at the target throughput, and measure actual resource consumption. Adjust the plan based on measured values, not calculated values.
Single-node scaling. At some point, vertical scaling (bigger hardware) hits limits. Plan the transition to horizontal scaling (more nodes) before you need it. A sharded deployment requires application-level changes that take weeks to implement.
Next step
Calculate your current capacity utilization. Pull the actual numbers: vector count, storage used, memory used, peak query throughput, and p95 latency. Compare these against your current hardware or tier limits. If any dimension exceeds 70% utilization, start planning expansion now. If all dimensions are below 70%, project when they will hit 70% at your current growth rate and put the expansion planning on your calendar for two months before that date.