Do the vector-storage math early

Budget for the size of the operating index, not the size of the raw vectors, and you'll avoid the surprise resize that always seems to land on a Friday. That's the whole rule. Everything past this paragraph is me explaining why the raw number lies to you and what I actually check before I trust a vector store's footprint on disk.

I test this against a million-chunk local knowledge base, a deliberately unglamorous setup: no lab conditions, no claim that it maps onto your machine. Before touching a config file, write down the actual job, chat retrieval, code search, an overnight reindex, whatever it happens to be, and decide what a passing result looks like. Skip that step and you'll spend an afternoon optimizing a number nobody asked about.

Where the float count stops telling the truth

The trap is multiplying row count by dimension and calling that your disk requirement. It's the first thing anyone reaches for, and it's wrong in a specific, boring way. That number is the payload. It says nothing about the index structure built on top of it, the metadata fields riding alongside every vector, the replicas your database keeps for availability, or the scratch space a rebuild needs while the old index still has to serve traffic. Picking a smaller embedding dimension, the kind of call you make back in choosing-an-embedding-model, shrinks the payload. It does almost nothing for the graph structure an index like HNSW builds around it, which is where a lot of the real disk and memory pressure actually lives.

Precision plays the same trick on you. Dropping to a lower-precision vector cuts the payload on paper, and "it loaded" still isn't a performance result, any more than "the answer looked fine" counts as an evaluation. Check runtime logs and OS-level memory and disk metrics instead of trusting whatever flag you passed at startup. Requested and delivered are two different numbers, and only one of them shows up on the invoice at the end of the month.

What actually goes into the estimate

The workable method: before sizing hardware, estimate raw vectors, index amplification, metadata, replicas, and rebuild headroom, in that order, and use the same inputs on every run so the numbers stay comparable across attempts. Save the exact launch command next to each result. One warm run tells you almost nothing; include a cold start if your users will ever hit one, and run long enough to expose thermal throttling or queueing that a two-minute test won't show you.

What's worth recording is short: time to first result, indexing throughput, query latency, peak memory, wall power if that matters for where the box lives, and whether the retrieved chunks were actually the right ones. Medians describe the ordinary case; a slow percentile is what your users will complain about, so keep that number too. Change one variable at a time and say out loud what you expect it to do before you run it, or the whole exercise turns into a pile of anecdotes with numbers taped on.

The tax you keep paying after the win

Here's the part people skip: a five-percent size win from hand-tuning HNSW parameters on one collection is fragile, and it evaporates the next time the embedding model, the driver, or the database version changes underneath you. I wouldn't bother chasing that win by hand unless the collection is enormous and genuinely static. Keep a small script, a fixed set of representative queries, and a plain-text result file instead, cheap enough that retesting after an upgrade takes minutes instead of an afternoon rebuilding a dashboard nobody else will open.

That's the actual decision rule: budget for the operating index and its upkeep, test the smallest plausible change first, and stop tuning the moment the setup meets its latency and quality target. Spare capacity is what absorbs a longer prompt, a background job, or the next embedding model you'll want to try, and it costs real money sitting there mostly unused. I take that tradeoff on purpose. Some disk stays empty, some percentage of theoretical density goes unclaimed, and I give that up in exchange for never staring at a full index at the worst possible hour.