Skip to content
ansezz.

▸ Free tool

pgvector Size Calculator.

How big will the table be, how big is the HNSW or IVFFlat index, and how much RAM do you need? Enter rows and dimensions and get the numbers before you run CREATE INDEX.

▸ Estimate, not a promise

Sizes follow the pgvector source and the Postgres page layout, for a fresh build. Check the real thing with pg_relation_size.

One row per chunk you embed, not per document.

pgvector default is 16. ef_construction changes build time and recall, not size, so it is not an input here.

Average size of everything besides the id and the vector. A bigint foreign key is 8, a timestamptz is 8, a short text is its length plus 1. Large text that Postgres moves to TOAST on its own is not counted.

▸ Estimated size

Table
0
Vector index
0
Total on disk
0
RAM to keep index hot
0
maintenance_work_mem to build
0
How it adds up

Sizes in 1024 steps, like pg_size_pretty · runs in your browser

The formulas, briefly

One vector. From the pgvector README: a vector value takes 4 × dims + 8 bytes, a halfvec takes 2 × dims + 8, and a bit value takes dims / 8 + 8. So vector(1536) is 6,152 bytes and halfvec(1536) is 3,080.

The table. Postgres stores rows on 8 KB pages. Each row has a 24 byte header, a 4 byte pointer on the page, then the columns. The tool assumes an id bigint primary key, your other columns, and the vector. If the row is bigger than about 2 KB, Postgres moves the vector to the TOAST table in chunks of up to 1,996 bytes, and only an 18 byte pointer stays in the row. That is why a table of 1536 dim vectors is mostly TOAST. Table size here means heap, TOAST, the TOAST index and the primary key index together.

HNSW. Each row becomes an element tuple of 72 + vector size bytes plus a neighbor tuple of 4 + 6 × (level + 2) × m bytes. Most rows sit only on level 0, where they keep 2 × m links. A few rows climb higher levels, with a chance of 1 in m per level. The tool packs these tuples onto 8 KB pages the way pgvector does. With large vectors that means about one row per page, so 1 million rows of vector(1536) is close to 1 million pages, or 7.6 GB.

IVFFlat. The index holds one center per list, then every row again as an index tuple of about 8 + vector size bytes, grouped by list on 8 KB pages. It is a little smaller than HNSW, but recall depends on how many lists you probe. The build runs k-means on a sample of max(50 × lists, 10,000) rows, which sets its memory.

RAM. HNSW search reads graph pages all over the index, so for steady low latency the whole index should be in shared_buffers or the OS page cache. That is the RAM number. The build number is what the in-memory graph needs during CREATE INDEX, so set maintenance_work_mem at least that high for the build session.

Ways to make it smaller

  • Index a halfvec expression. Keep the full vector column and create the index on (embedding::halfvec(1536)) halfvec_cosine_ops. The index roughly halves. Queries must use the same cast.
  • Use fewer dimensions. Many embedding models can return shorter vectors. Going from 3072 to 1024 cuts storage by two thirds, and 3072 dim vectors cannot be indexed as plain vector anyway (the limit is 2,000).
  • Lower m. m of 8 instead of 16 shrinks the neighbor tuples, but with big vectors the vector itself dominates, so the saving is small and recall drops. Test before you change it.
  • Partition or filter. Many smaller indexes (per tenant, per language) each need less RAM than one big one, and only the busy ones stay hot.

Questions, answered

How much disk space do 1 million embeddings take in pgvector?

It depends on the dimensions and the type. A vector(1536) value is 4 x 1536 + 8 = 6,152 bytes, so 1 million rows hold about 6 GB of raw vectors. In Postgres that lands at about 7.8 GB for the table, because each vector is moved to the TOAST table in 2 KB chunks, plus another 7 to 8 GB for an HNSW index with the default m of 16. Switch to halfvec and both numbers roughly halve.

How much RAM does a pgvector HNSW index need?

For fast queries, enough to keep the whole index in memory: shared_buffers plus the operating system page cache should be at least the index size shown above. HNSW search jumps around the graph, so an index that does not fit in RAM turns into random disk reads and latency goes up sharply. Building the index needs memory too. If maintenance_work_mem is smaller than the graph, pgvector warns that the graph no longer fits and the build gets much slower.

What should I set maintenance_work_mem to for an HNSW build?

Set it to at least the build memory number this calculator shows, for the session that runs CREATE INDEX, for example SET maintenance_work_mem = '8GB'. Do not set it higher than the RAM the server can spare. With parallel builds (max_parallel_maintenance_workers), the graph lives in shared memory and is a bit smaller, but the same rule applies.

Should I use vector or halfvec?

halfvec stores each dimension in 2 bytes instead of 4, so the table and the index are about half the size, and you can index up to 4,000 dimensions instead of 2,000. For most text embeddings the recall loss is very small. A common setup is to keep the full vector column and build the index on a halfvec expression, which halves the index without changing the stored data.

Why is my real index bigger than this estimate?

This is the size right after a clean build. Rows inserted after the build, updates and deletes leave the graph less tightly packed, and VACUUM does not shrink the file. Different Postgres or pgvector versions also move the numbers a little. Treat the result as a planning number, then check the real size with SELECT pg_size_pretty(pg_relation_size('your_index')).

Does this calculator send my numbers anywhere?

No. All the maths runs in JavaScript in your tab. There is no request, no login and no logging. The share button only puts your inputs in the page address so you can send the link to someone.

▸ Last verified:

Need this in production?

Shipping AI features? I build RAG pipelines, MCP servers and agents that hold up in production.

AI & MCP Integration

Also related: Architecture Audit .

Keep reading