Estimate the raw vector storage for 10 million 768-dim float32 embeddings before any index overhead.

Predict output·Easy·4.0 · 0·~2 min·Asked atAmd Hugging Face Uniphore

Attempt it

Your team is sizing a new vector database deployment. The corpus is 10,000,000 documents, each embedded once with a 768 dimension model stored as float32 (4 bytes per dimension). Ignoring graph or index overhead, metadata, and replication, estimate the raw storage for the vectors alone.

**The math is straightforward.** Each dimension of a float32 vector is 4 bytes. A 768-dimension vector takes `768 * 4 = 3,072` bytes, which is roughly 3 KB. Ten million such vectors: `10,000,000 * 3,072 = 30,720,000,000` bytes, or about 30.7 GB. That is the **raw vector storage** floor: just the embeddings, no graph, no metadata, no replication. Why this matters. Every capacity planning conversation for a vector database starts with this calculation. Sales-engineering responses, vendor pricing pages, and architecture review decks all anchor on `dim * 4 * count`. If you cannot estimate this number quickly, you cannot price an architecture. The real deployment is larger. HNSW indexes add roughly 30-50 percent on top of raw storage for graph links. Payload or metadata columns add more. Replication multiplies by your replica factor. So 30 GB raw translates to roughly 50-100 GB of actual storage and RAM consumption depending on configuration. The raw number is the floor, not the ceiling. Also worth knowing: float16 cuts storage in half (2 bytes/dim), int8 quantization cuts to a quarter (1 byte/dim), and binary or product quantization can push much further. Modern deployments rarely use float32 in production for cost reasons.

**The arithmetic.** Per vector: `768 dims * 4 bytes/dim = 3,072 bytes`. For 10M vectors: `10,000,000 * 3,072 = 30,720,000,000 bytes`, which is 30.72 GB (decimal) or 28.6 GiB (binary). This is the **raw floor**. Real deployments add at least three layers on top: - **Index overhead.** HNSW adds roughly 30-50 percent for graph links (`m` connections per node, each link is typically 4-8 bytes). IVF adds a smaller fraction for the centroid table plus inverted lists. For an 8M-row HNSW at `m=16`, expect roughly 10 GB of graph data on top of the 30 GB vectors. - **Metadata.** Filter columns, document IDs, timestamps. Often 100-500 bytes per row, adding 1-5 GB for 10M rows. - **Replication.** A 3x replication factor triples everything. A realistic total: roughly 50-150 GB on disk and RAM depending on replication and metadata richness. The raw 30 GB is the conversation starter. **Quantization changes this dramatically.** Float16 halves it to 15 GB. Int8 (scalar quantization) quarters it to 7.5 GB. Product quantization with 8 subspaces and 256 centroids per subspace can push the same corpus to under 100 MB at acceptable recall. Production deployments at large scale almost always quantize; raw float32 is the textbook number for sizing, not the deployment reality.

TL;DR

About 30 GB: 10M vectors x 768 dims x 4 bytes = 30.72 GB raw. The real deployment adds graph links, metadata, and replicas on top of this floor.

Memory aid

Easy to grasp

A vector is just a list of decimal numbers. Each one takes 4 bytes in standard precision. If a single embedding has 768 numbers, that is about 3 kilobytes. Now imagine 10 million of these embeddings sitting in a database; multiply 3 KB by 10 million and you get roughly 30 gigabytes. That is the size of the raw data, like the weight of all the bricks before you build the house. The actual database will be bigger because it needs walls, doors, and a roof on top of the bricks: the index, the metadata, and the replicas. But the brick count is always the starting point of any capacity conversation.

Key concepts

Vector Databases

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Estimating raw vector storage is the first arithmetic any vector-database engineer learns and the one that becomes muscle memory after the third capacity-planning meeting. The formula is simple enough to do in your head: dimension times bytes-per-dim times count. The trap is treating the raw number as the deployment total, when in practice the real budget is 2x to 4x larger after index overhead, metadata, and replication.

This deep-dive walks through the formula and its derivation, the three layers of overhead on top of the raw number, the role of quantization as the primary cost lever at scale, and the unit conventions (decimal GB vs binary GiB) that catch teams out in surprising ways.

The formula and its derivation

The arithmetic

A float32 number is 4 bytes (32 bits). A vector of dim float32 numbers is dim * 4 bytes. A corpus of N such vectors is N * dim * 4 bytes.

\text{bytes}_{\text{raw}} = N \cdot d \cdot b

where N is vector count, d is dimension, and b is bytes per dimension (4 for float32, 2 for float16, 1 for int8).

For the question: N = 10,000,000, d = 768, b = 4. So:

10,000,000 \cdot 768 \cdot 4 = 30,720,000,000 \text{ bytes}

Divide by 10^9 for decimal gigabytes: 30.72 GB. Divide by 2^30 for binary GiB: 28.6 GiB.

Why this is the right starting point

Every downstream sizing decision (RAM, disk, network, replication) anchors on this number. Get this wrong by an order of magnitude and the architecture review is wrong by an order of magnitude. Get this wrong by 2-3x and you ship a cluster that runs out of RAM in week four.

Memorize the per-vector size for common dimensions:

384 dim float32: 1.5 KB.
768 dim float32: 3 KB.
1024 dim float32: 4 KB.
1536 dim float32: 6 KB.
3072 dim float32: 12 KB.

Multiply by your corpus size to get the raw number in seconds, without a calculator.

The three overhead layers on top of raw

Quantization as the cost lever at scale

Units and other gotchas

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Real products, models, and research that use this idea.

Pinecone capacity calculators expose exactly this formula in their UI; users enter dim, count, and quantization to get sizing.
Pgvector documentation walks through the same calculation when advising on `shared_buffers` and instance sizing.

What an interviewer would ask next. Try answering before peeking at the approach.

QHow does the formula change for a billion-vector deployment, and at what scale does float32 stop making sense?

Same formula: 1B * 768 * 4 = 3 TB. With 3x replication that is 9 TB just for vectors before any index or metadata. The crossover where quantization becomes mandatory is usually around 100M-500M vectors depending on hardware budget; above that, scalar or product quantization is the default.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Treating 30 GB as the deployment total. Real HNSW adds 30-50% on top for graph links, plus metadata, plus replicas. Budget at least 2x the raw figure.

60 second bullets to scan on the way to the call.

Per-vector size formula: dim times bytes-per-dim
Float32 = 4 bytes, float16 = 2 bytes, int8 = 1 byte

Primary sources. Browse if you want the original framing.