A sizing table you can change
The 8 bytes per row come from pgvector's documentation. The 32 links of 4 bytes are an assumption for HNSW, stated in the code, so check them against your own store.
How much memory and disk a vector store needs follows from three numbers you control: how many vectors, how many numbers each has, and how many bytes a number takes. Add the index, the copies and some headroom, and you can estimate before you buy.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write vector_bytes(n, dims, bytes_per_number=4) using pgvector's formula and print the size in MB (decimal) of 250,000 vectors of 1024 numbers with 2 decimals.
Write max_vectors(ram_mb, dims, bytes_per_number=4, overhead_bytes=128) that returns how many vectors fit in half of ram_mb, rounding down. Print it for 8,000 MB and 384 numbers.
Explain it without notes
How much memory do 2 million vectors of 768 numbers take (vectors only, 4 bytes a number, 8 bytes overhead)?
Why does the index add to the size, and why do you measure that part?
Name three ways to shrink a vector store.
What decides how many copies you need?
Expected output
scenario vectors MB index MB total MB fits in 16000 MB
5 thousand chunks, 384 7.7 0.6 8.4 yes
1 million chunks, 384 1544.0 128.0 1672.0 yes
1 million chunks, 1536 6152.0 128.0 6280.0 yes
same, 2 bytes a number 3080.0 128.0 3208.0 yes
100 million, 384, 3 copies 154400.0 12800.0 501600.0 no