What It Does

Two questions decide the shape of a vector search deployment: how much memory the index needs, and whether to self-host or use a managed service. This tool answers both.

Enter your vector count, dimensions, precision (float32 / float16 / int8), and index type, and it breaks down the RAM:

Raw vectors - N × dimensions × bytes-per-value, the irreducible core
Index overhead - HNSW adds a navigation graph (roughly N × M × 2 links × 4 bytes); IVF adds centroids and assignments; Flat (exact search) adds nothing
Metadata - the payload you store alongside each vector

Then it compares a self-hosted monthly cost (total GB × your $/GB-RAM rate) against a managed estimate ($/million vectors), and tells you which wins and by how much per year.

Why The Overhead Matters

The raw vectors are the easy part; it’s the index structure people forget. An HNSW graph over a few million vectors can add gigabytes on top of the vectors themselves, and that’s what pushes you into a bigger instance. Seeing raw / index / metadata split out makes the real driver obvious - and shows why dropping from float32 to int8, or choosing IVF over HNSW, changes the bill.

Pairs with the Embedding Playground for the vectors themselves, the GPU VRAM Calculator for the compute box, and the RAG Chunk Inspector upstream.

Limitations

In-memory estimate. Many databases (pgvector, disk-backed FAISS, managed tiers) can keep part of the index on disk, trading memory for latency - this models the fully-in-RAM case, the usual worst case.
Overhead formulas are approximations. Real overhead varies by implementation (FAISS vs hnswlib vs pgvector vs a managed engine) and by build parameters; product quantization (PQ) can shrink vectors far below the raw figure.
Costs are rough, editable defaults - not a live pricing feed. Confirm against your instance type and provider; replicas and high-availability multiply both sides.