Vector Database Size Calculator

A library of 100,000 documents becomes one million vectors if each document produces ten chunks and each chunk receives one embedding. An embedding is a list of numbers representing a piece of content. A vector index organizes those representations for similarity search, including retrieval-augmented generation (RAG), where retrieved content supplies context for a generated answer. Counting the actual embeddings avoids sizing a collection as though every document produced only one searchable item.

Each number in an embedding occupies one dimension. The numeric payload grows with both the number of dimensions and the bytes used to store each number. Float32 uses four bytes per dimension, while an 8-bit representation uses one. That reduces the vector payload to a quarter of its original size. Graph links, identifiers, and stored text still occupy space, so the same reduction does not automatically apply to the complete index.

The search method adds another cost. A Flat index compares a query against every stored vector and needs no neighbor graph. Hierarchical Navigable Small World (HNSW) search follows links between vectors and can find nearby candidates without examining the entire collection. Those links consume memory. Its connectivity setting, M, controls the graph's neighbor budget; increasing it uses more memory and can improve retrieval, with the outcome depending on the data and search settings.

Random-access memory (RAM) and disk storage meet different needs, even when they contain copies of the same vector data.

Resident RAM

The memory occupied by the vectors and supporting data kept available for search.

Provisioned RAM

The memory capacity allocated to hold that resident data plus a chosen unused reserve.

Stored disk

The persistent copies of vectors and supporting data, including any original vectors retained alongside compressed representations.

Once frequently accessed data no longer fits in RAM, a database using memory-mapped storage may repeatedly retrieve evicted data from disk. HNSW traversal can involve many small reads, making storage latency consequential. Keeping only the frequently used representation in RAM can reduce this pressure, but the total disk footprint alone cannot predict query speed. Available cache, storage speed, concurrent queries, and the search workload also matter.

Reducing precision exchanges numerical detail for a smaller representation. Quantization can change which neighbors a search retrieves. Recall measures how many of the neighbors found by an exact reference search are recovered, so a smaller byte count needs a retrieval-quality check. Keeping full-precision originals allows rescoring, which recalculates scores for retrieved candidates using those originals. Originals stored on disk still need disk capacity, and reading them can add latency. Rescoring can reorder retrieved candidates but cannot recover a neighbor that never reached that candidate set.

Metadata can become a substantial part of the footprint after vectors shrink. Stored chunk text, document references, and filtering information need their own allowances. Replication adds copies of the dataset, while sharding distributes portions of it across machines. A per-dataset estimate therefore needs a separate deployment decision about copies and placement. Index construction, database maintenance, and the operating system also need resources beyond the stored vectors and links.

How to Use This Tool:

Describe one complete dataset before replication. Results update as valid inputs change.

1. Choose Vector count when you know the total embeddings, or Documents × chunks to estimate one vector per chunk. Use direct vector entry when a whole-number average of chunks per document would distort the count.
   The calculation runs in your browser from sizing assumptions and needs no database connection or vector upload. Settings can be included in the page address and shared links.
2. Enter the actual Embedding dimensions and select the intended Search-vector precision. For FP16, Int8, or 1-bit, set Full-precision originals to reflect whether a separate float32 copy should count toward disk storage.
3. Choose Search index. HNSW adds a graph allowance controlled by HNSW connections (M); Flat removes that allowance.
4. Enter average byte allowances for Resident metadata per vector and External IDs per vector under Advanced. Both start at zero. Include stored chunk text here only when it belongs in both the resident and persisted budget.
5. Set Total dataset copies, including the primary, and Keep provisioned RAM free for the intended reserve. One primary plus one replica means two copies. The defaults are one copy and a 0% reserve.
6. Compare the per-copy RAM, disk, and minimum modeled tier in Precision options. Check the selected representation's allowances in Byte breakdown before choosing a configuration to benchmark.
   If Sizing inputs need attention appears, correct the field named in the message. Reopen Advanced if that field is hidden there. Results return automatically when the active inputs are valid.

Interpreting Results:

Provisioned RAM across all copies is the fleet total, including the selected reserve. The modeled disk value beside it also covers all copies. For one complete, unsharded copy, use the per-copy columns. A minimum modeled RAM tier covers only the stated assumptions; measure the chosen database with representative data, filters, ingestion, and queries before selecting production capacity.

• Byte breakdown reports resident RAM before reserve. Precision options includes reserve in its RAM columns, so those totals differ whenever the reserve is greater than zero.
• RAM vs float32 (%) is the percentage of the float32 RAM requirement that remains, rather than the percentage saved. It includes the unchanged graph, metadata, and ID allowances.
• All precision rows use the same count and capacity assumptions. The retained-originals choice still governs compressed rows after switching back to FP32 and hiding that control.
• In Precision options, Min modeled tier / copy (GiB) contains a numeric tier or a blank cell. Modeled tier status shows within_modeled_range for a numeric tier and above_modeled_range for a blank tier cell. CSV, row copy, and DOCX preserve the same tier and status values.

Scale checkpoints compares the entered count with 1 million, 10 million, and 100 million vectors, combining duplicate counts. Capacity curve varies the count from zero to twice the entered value while keeping other assumptions fixed. Its straight lines show sensitivity to corpus size; they do not forecast growth over time or search performance.

Technical Details:

A dense vector's numeric payload follows a fixed byte budget once its dimensions and representation are chosen. Graph storage adds an approximation, while metadata and external IDs add user-supplied allowances. The arithmetic can be exact for those assumptions without being a measurement of a database's allocated memory or files.

Formula Core

Let N be the vector count for one dataset, D the embedding dimensions, C the total dataset copies, and h the percentage of provisioned RAM intended to remain unused. Document entry obtains N by multiplying documents by the whole-number average of chunks per document. Resident bytes per vector, B, are the sum of four contributions.

All four resident contributions are also counted as persisted disk bytes. Additional originals contribute only to disk. Float32 already supplies the full-precision representation, so it never receives a second originals allowance.

Multiplying by N gives the bytes for one complete copy. Resident RAM has no reserve; provisioned RAM divides that resident requirement by the fraction allowed to be occupied. Disk receives no reserve.

Here R denotes RAM and S denotes stored disk, both in bytes. Fleet totals multiply the per-copy provisioned RAM and disk by C, including the primary copy.

A 25% unused-memory target leaves 75% available for the resident data. For a resident requirement of 6 GiB, the provisioned amount is 8 GiB.

That leaves 2 GiB unused. Adding 25% to the resident requirement would provide 7.5 GiB and leave only 20% of that total unused. A reserve is a capacity assumption, with no guarantee that it covers every excluded operating cost.

Precision and byte packing

The payload formulas count stored numbers before graph, ID, metadata, and original-vector allowances. D is the number of dimensions in each vector.

Float16 and bfloat16 both use two bytes per dimension, although their numerical formats differ. This shared byte width does not establish support in a particular database. Int8 and binary budgets likewise describe representation sizes without selecting a quantization algorithm or predicting its accuracy.

Binary packing rounds each vector separately. At 1,537 dimensions, the payload is 193 B per vector with 7 padding bits. Rounding the combined bits for an entire collection would undercount this per-vector padding. FAISS binary indexes require byte-aligned dimensions; the packed estimate does not establish that a database accepts an arbitrary dimension or that the original embeddings can be used as binary vectors unchanged.

Graph allowance and retained originals

The HNSW allowance follows published FAISS sizing guidance: two times M link entries at four bytes each. It therefore adds 8 bytes per unit of M to each vector, or 128 B at M set to 16. This is an approximate graph budget. Actual graph levels, bookkeeping, and allocation differ by engine. Flat sets the graph allowance to zero while preserving any entered ID and metadata allowances.

A full scan over compressed representations still compares compressed values. Exhaustive search alone does not restore the ranking that the original float32 vectors would produce. Likewise, increasing M changes the memory allowance without establishing a particular recall or latency.

Retained originals add four bytes per dimension on disk alongside the selected compressed search representation. Reducing resident precision can therefore increase disk usage compared with keeping only float32 vectors. All metadata and ID allowances are counted once per vector in both RAM and disk, with no automatic database-specific multiplier.

Units, precision, and memory tiers

One decimal GB contains 1,000,000,000 B. One GiB contains 1,073,741,824 B; KiB and MiB contain 1,024 B and 1,048,576 B respectively.

The summary and chart choose B, KiB, MiB, or GiB and show at most two decimal places. Capacity tables retain calculated byte values. Tier selection uses the unrounded per-copy RAM requirement.

Intermediate calculations are not deliberately rounded. Very large fleet totals can lose single-byte precision. Fractional reserve percentages can also produce fractional byte estimates. Extra displayed digits do not turn an approximate graph or metadata allowance into measured capacity.

Memory tiers are powers of two, selected using provisioned RAM for one complete copy. The minimum modeled tier follows this rule.

1. Start at 1 GiB.
2. Double the tier until it meets or exceeds the per-copy requirement, or reaches 4,096 GiB.
3. If the requirement still exceeds 4,096 GiB, leave the tier cell blank and show above_modeled_range in Modeled tier status.

Equality fits the smaller tier. Exactly 8 GiB maps to 8 GiB, while any requirement above 8 GiB and at most 16 GiB maps to 16 GiB. Copies increase fleet totals without changing this per-copy threshold.

Accepted sizing ranges

Counts, dimensions, connections, byte allowances, and copies require whole numbers. The reserve accepts percentages from 0% through 80%, including fractional values. Documents multiplied by chunks must not exceed 1,000,000,000 vectors.

Limitations:

The estimate assumes all search vectors, graph allowances, external IDs, and entered metadata are resident and persisted. It assigns retained originals to disk only. This fixed arrangement cannot reproduce every database's memory placement or file layout.

• Database headers, additional graph storage, quantization scales or codebooks, and indexes used to filter metadata are additional costs.
• Write-ahead logs, deleted records awaiting cleanup, compaction, backups, operating-system memory, caches, and peak query or index-building memory are excluded. Disk has no automatic spare-capacity allowance.
• Sharding overhead, sparse-vector indexes, and additional embedding representations require separate estimates. The memory tier does not determine server count, query throughput, or provider charges.
• Omit from this estimate removes the originals allowance from the arithmetic. Check whether the chosen database can operate without those originals. For example, Qdrant requires its original vectors when rebuilding quantized representations. A storage estimate does not establish that deleting them is supported.

Worked Examples:

References:

• Faiss indexes, Meta.
• Guidelines to choose an index, Meta.
• Binary Indexes, Meta.
• Quantization, Qdrant.
• Capacity Planning, Qdrant.
• Measuring ANN Recall, Qdrant.
• Qdrant Fundamentals, Qdrant.