How many vectors will my documents make?

One per chunk. Divide each document's tokens by the chunk size, allowing for overlap, and multiply by the number of documents. A page is about 500 words, or about 670 tokens, so a 10-page document makes 11 chunks of 800 tokens with a quarter overlap, and 5,000 of them make about 55,000 vectors. Short items such as products or tickets usually make one each.

How big is one embedding vector?

Its length times the bytes of each number. In pgvector, a vector takes 4 × dimensions + 8 bytes, a half-precision vector 2 × dimensions + 8, and a bit vector dimensions ÷ 8 + 8. A 1,536-number vector is 6.2 KB at full precision.

How much does binary quantization save?

It keeps 1 bit for each number instead of 32, so the index's vectors take about a 32nd of the space. In the example, the index in 3 years drops from 843 MB at full precision to 431 MB at half precision and 44 MB as bits; the HNSW links stay the same size. Recall drops too, so pgvector's guide re-ranks the top results by the full vectors, which the table keeps.

Can pgvector index 3,072-dimension embeddings?

Not at full precision: pgvector's HNSW and IVFFlat indexes take vectors of up to 2,000 dimensions. Index them at half precision, which goes to 4,000, as bits, which go to 64,000, or ask the model for shorter vectors, which text-embedding-3-large can return through its dimensions parameter.

Should I choose HNSW or IVF?

HNSW when memory allows: it answers faster for the same recall, at the cost of more memory and slower builds. IVF builds faster and uses less memory, with lower recall for the same speed, and needs data in the table before the index is built, since it learns its list centres from it. pgvector starts IVF at rows ÷ 1,000 lists up to a million rows and the square root of the rows above.

The most links each vector keeps on a layer; pgvector's default is 16. A higher m finds neighbours more reliably and uses more memory: each vector keeps m × 2 links of 4 bytes on the bottom layer, 128 bytes at 16.

How do I make an HNSW index build faster?

In pgvector, give the build enough memory: indexes build much faster when the graph fits in maintenance_work_mem. Set it to about the index size for the build, but never so high that it exhausts the server's memory.

How big will your vector database be?

5,000 documents of 10 pages make about 55,000 vectors; with text-embedding-3-small and an HNSW index, search wants 345 MB in memory, and 843 MB in 3 years at 200 new documents a month.

Most people know what they have, not how many vectors it makes. Say what you have and how much, how it grows, and the embedding model. The calculator cuts it into chunks, counts the vectors and shows the memory and disk they take with each number format and index, step by step.

Size your database Questions

What you have

How many documents

documents

PDFs, manuals, contracts and reports, each cut into chunks.

Pages in each, on average

pages

A starting guess; set your own. About 6,667 tokens.

Added each month

documents

Embedding model

Keep the chunk text with the vectorsSo search returns the passage, not only its id.

The answer

55,000 vectors today and 134,200 in 3 years. Search wants 345 MB in memory now and 843 MB in 3 years, with 2.1 GB on disk.

In memory, on each copy: 843 MB
On disk: 2.1 GB

Table: full vectors, 826 MB
Index: vectors at full, 826 MB
Index: HNSW links, 17.2 MB
Chunk text, 423 MB

How it adds up, in 3 years

5,000 documents, plus 200 a month for 36 months, each about 6,667 tokens, cut into chunks of 800 with a quarter overlap: 11 chunks each, 134,200 vectors.
Each vector has 1,536 numbers (text-embedding-3-small). At full precision that is 6.2 KB a vector.
The HNSW index keeps its own copy of each vector and 32 links of 4 bytes on its bottom layer, 128 bytes a vector. The whole index is 843 MB, which search wants in memory.
The table keeps every vector at full precision to return and re-rank with: 826 MB.
The chunk text, at about 4 characters a token: 423 MB.

A server with 4 GB of memory leaves room for the index in 3 years, at our rule of thumb of twice its size. In pgvector, the index builds much faster when its graph fits in maintenance_work_mem, so set it near 345 MB for the first build, without exhausting the server's memory.

What it costs to embed these documents

The least you will need: each database adds its own pages, headers and logs, and some keep more than one layer of links.

How the calculator works it out

First the vectors. A document is cut into chunks of the size you choose, and with overlap each chunk starts before the last one ends, so a sentence cut at one boundary is whole in the next. A page is taken as 500 words and a token as 0.75 of a word, so a 10-page document of about 6,700 tokens makes 11 chunks of 800 tokens with a quarter overlap. Each chunk is one vector. A product or a row is one vector whatever its length.

Then the bytes. A vector is a list of numbers as long as the model's output: 1,536 for text-embedding-3-small. At full precision each number takes 4 bytes, plus 8 bytes beside the vector, so one vector is 6.2 KB. Half precision takes 2 bytes a number, an 8-bit format 1, and binary quantization 1 bit, a 32nd of full.

An index makes search fast. HNSW links each vector to its neighbours on several layers; on the bottom one it keeps m × 2 links of 4 bytes, 128 bytes at the default m of 16. IVF sorts vectors into lists around centres and searches only the nearest lists, with less memory and lower recall for the same speed. The index holds its own copy of the vectors, at the format you choose, while the table keeps the full-precision vectors to return and re-rank with.

Search is fast while the index is in memory, so memory is the figure to plan for. Disk holds the table, the index and the chunk text, at about 4 characters a token, on every copy. The suggested server memory is our own rule of thumb: at least twice the index, since the database, its cache and index builds need room too. Treat every figure as the least you will need: each database adds its own pages, headers and logs.

Questions

How much memory does a vector database need?: About the size of its index: for HNSW, each vector's numbers times their bytes, plus 8, plus m × 2 links of 4 bytes. 5,000 documents of 10 pages, cut into 800-token chunks, make about 55,000 vectors; with text-embedding-3-small's 1,536 numbers at full precision and m = 16, the index takes 345 MB. At 200 new documents a month it reaches 843 MB in 3 years, which suits a server with 4 GB of memory.
How many vectors will my documents make?: One per chunk. Divide each document's tokens by the chunk size, allowing for overlap, and multiply by the number of documents. A page is about 500 words, or about 670 tokens, so a 10-page document makes 11 chunks of 800 tokens with a quarter overlap, and 5,000 of them make about 55,000 vectors. Short items such as products or tickets usually make one each.
How big is one embedding vector?: Its length times the bytes of each number. In pgvector, a vector takes 4 × dimensions + 8 bytes, a half-precision vector 2 × dimensions + 8, and a bit vector dimensions ÷ 8 + 8. A 1,536-number vector is 6.2 KB at full precision.
How much does binary quantization save?: It keeps 1 bit for each number instead of 32, so the index's vectors take about a 32nd of the space. In the example, the index in 3 years drops from 843 MB at full precision to 431 MB at half precision and 44 MB as bits; the HNSW links stay the same size. Recall drops too, so pgvector's guide re-ranks the top results by the full vectors, which the table keeps.
Can pgvector index 3,072-dimension embeddings?: Not at full precision: pgvector's HNSW and IVFFlat indexes take vectors of up to 2,000 dimensions. Index them at half precision, which goes to 4,000, as bits, which go to 64,000, or ask the model for shorter vectors, which text-embedding-3-large can return through its dimensions parameter.
Should I choose HNSW or IVF?: HNSW when memory allows: it answers faster for the same recall, at the cost of more memory and slower builds. IVF builds faster and uses less memory, with lower recall for the same speed, and needs data in the table before the index is built, since it learns its list centres from it. pgvector starts IVF at rows ÷ 1,000 lists up to a million rows and the square root of the rows above.
What is m in HNSW?: The most links each vector keeps on a layer; pgvector's default is 16. A higher m finds neighbours more reliably and uses more memory: each vector keeps m × 2 links of 4 bytes on the bottom layer, 128 bytes at 16.
How do I make an HNSW index build faster?: In pgvector, give the build enough memory: indexes build much faster when the graph fits in maintenance_work_mem. Set it to about the index size for the build, but never so high that it exhausts the server's memory.

Put this calculator on your own site

Copy the code into any web page: a blog post, a course page or your team's wiki. The calculator runs in a frame and shows the same figures as this page, so when the prices change here they change on your page too. It is free and needs no account, and nothing a reader types is sent anywhere.

The code opens the calculator with the settings you have chosen above.

The short script at the end lets the frame grow and shrink with the calculator. Where a page cannot take scripts, choose a fixed height and the frame scrolls.

<iframe src="https://tecyfy.com/embed/vector-database-size" title="Vector database size calculator" width="100%" height="2600" style="border:0;display:block" loading="lazy" allow="clipboard-write"></iframe>
<p><a href="https://tecyfy.com/ai-agents/vector-database-size">Vector database size calculator</a> by Tecyfy</p>
<script>addEventListener("message",function(e){if(e.origin!=="https://tecyfy.com"||!e.data||e.data.type!=="tecyfy:height")return;var h=Number(e.data.height);if(!(h>0))return;document.querySelectorAll("iframe").forEach(function(f){if(f.contentWindow===e.source)f.style.height=Math.min(h,20000)+"px"})})</script>

Sources

The vector database size calculator

How the calculator works it out

Questions

Put this calculator on your own site

Where each fact comes from