In this article
Coordinate arithmetic describes a representation, not the whole search service; dimension changes also require a supported quality-preserving method.
Start embedding-memory estimation with N × D × B: vector count, dimensions and bytes per coordinate. This is useful budgeting arithmetic, but it describes only the selected coordinate representation. The complete search service also includes indexes, IDs, metadata, caches and operational requirements that must be assessed separately.
Count fragments and define units
A source file may produce many chunks, so record vectors rather than documents alone. Preserve the embedding model, dimension and numeric representation in the estimate. A change to any of those inputs should update the calculation instead of becoming an unnoticed technical detail.
Keep bytes, decimal gigabytes and binary units distinct. A smaller number after conversion does not create more physical memory. Also distinguish RAM, disk storage and VRAM: where a representation is stored depends on the chosen implementation, not merely the result of the formula.
Work through an explicit example
For one million vectors with float32 coordinates, the coordinate-only arithmetic is:
| Dimensions | Calculation | Raw bytes |
|---|---|---|
| 384 | 1000000 × 384 × 4 | 1,536,000,000 |
| 768 | 1000000 × 768 × 4 | 3,072,000,000 |
| 1536 | 1000000 × 1536 × 4 | 6,144,000,000 |
These are illustrative calculations, not measured database sizes or recommendations for a particular model. The choice of dimension must still satisfy retrieval quality and the model’s supported representation. Do not use the smallest row as evidence that truncating any vector is safe.
Add the index and application
Different index families store graphs, IDs, partitions or compressed codes differently. FAISS documents these distinctions, while Qdrant capacity guidance considers collection components. There is no universal overhead multiplier that makes every service estimate exact.
Include payload fields, filter indexes, replicas and the application’s other memory consumers. Construction, updates and concurrent queries can create different peaks from an idle loaded collection. Record which stage each measurement represents so a low idle figure is not mistaken for the maximum requirement.
Validate dimension changes and the estimate
Use a supported dimension-reduction method only where the model and implementation provide one, and repeat retrieval evaluation afterwards. Equal vector length does not guarantee compatibility between models. Preserve the model and preprocessing identity with the collection.
Build a representative sample, measure ingestion and queries, then explain any extrapolation. A hardware owner can use the result to propose a specific RAM, storage or GPU role.
Official references: qdrant.tech — capacity planning, github.com — Faiss indexes.
Related guides: Qdrant for RAG: deciding what belongs in RAM or on disk, FAISS server memory: an index library versus a database service.