Database & AI Infrastructure
pgvector HNSW Index RAM & Sizing Calculator
Model PostgreSQL pgvector HNSW index memory requirements before deployment. Calculate RAM thresholds to prevent disk thrashing, optimize m and ef_construction parameters, and export tuned postgresql.conf and SQL DDL scripts.
1. Dataset & Vector Dimensions
Vector Count (Rows)1,000,000 vectors
2. Vector Precision & Quantization
3. HNSW Graph Hyperparameters
Higher m increases recall at the cost of index RAM and build time.
Controls graph build quality. Does not affect index RAM size.
Fast (20)Balanced (100)Max Recall (400)
4. PostgreSQL Host Server Specs
Memory & Sizing Estimates
Index fits cleanly in RAM
HNSW graph and vector payloads (7.05 GB) fit comfortably inside your 32 GB server memory for sub-15ms search latency.
HNSW Index Size (RAM):7.05 GB
Raw Table Footprint:6.39 GB
Total Recommended RAM:> 8.8 GB
Recommended maintenance_work_mem:7943 MB
Est. Index Build Time:~21s
Key SRE Rule for pgvector
Unlike B-tree indexes where partial cache hits still yield acceptable performance, HNSW vector search relies on non-local random graph walks. If the index spills from RAM to disk, latency degrades from 5ms to 800ms+.
-- 1. Enable pgvector extension
CREATE EXTENSION IF NOT EXISTS vector;
-- 2. Create optimized vector storage table
CREATE TABLE IF NOT EXISTS documents (
id BIGSERIAL PRIMARY KEY,
content TEXT NOT NULL,
metadata JSONB DEFAULT '{}'::jsonb,
embedding vector(1536) NOT NULL
);
-- 3. Set dedicated build memory for the current session (avoids disk spills)
SET maintenance_work_mem = '7943MB';
SET max_parallel_maintenance_workers = 6;
-- 4. Create HNSW index for sub-15ms semantic search
CREATE INDEX IF NOT EXISTS idx_documents_embedding_hnsw
ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (
m = 16,
ef_construction = 64
);Advertisement
How to use
- Step 1: Select your dataset scale (e.g. 100K, 1M, or 10M rows) and choose your embedding model (OpenAI 1536d, BGE 768d, etc.) or input a custom dimension.
- Step 2: Pick your vector quantization: standard float32 vector, float16 halfvec (50% RAM savings with ~99% recall), or binary bit representation.
- Step 3: Configure HNSW graph parameters: m (connections per node) and ef_construction (build candidate list).
- Step 4: Verify that the required RAM fits within 75% of your host server memory to guarantee sub-15ms search latency.
- Step 5: Copy the generated SQL DDL, postgresql.conf parameters, and asyncpg Python queries directly into your codebase.
Frequently asked questions
Why does a pgvector HNSW index need to fit entirely in RAM?
Unlike B-tree indexes where partial page reads from SSD are reasonably fast, HNSW searches perform non-local random graph traversals. If pages must be paged in from disk (even on fast NVMe SSDs), search latency degrades from 5ms to over 800ms per query. The index and vector payloads must reside in shared_buffers or OS page cache.
What is the memory difference between vector and halfvec?
Standard vector uses 4 bytes per dimension (32-bit floating point). pgvector 0.7.0+ introduced halfvec (16-bit floating point), which uses 2 bytes per dimension. This cuts raw vector table size and index memory consumption in half while retaining over 99% of retrieval recall in real-world benchmarks.
How do m and ef_construction affect index size and search speed?
The m parameter determines how many bidirectional links each vector stores in the graph layers (default 16). Higher m values increase index RAM size and build time, but improve recall for high-dimensional vectors. ef_construction controls search quality during graph creation; higher values build a cleaner graph but only increase build time, not the final index size in RAM.
What is the purpose of maintenance_work_mem when building HNSW?
PostgreSQL allocates maintenance_work_mem to construct the HNSW graph in memory. If maintenance_work_mem is smaller than the required graph construction buffer, PostgreSQL spills temporary files to disk, increasing index creation time by 10x to 50x. Setting maintenance_work_mem to at least 1GB to 4GB before running CREATE INDEX is critical.
How do I balance query latency vs recall at search time?
Use the session parameter SET hnsw.ef_search = N. The default is 40 (offering ultra-low latency, typically 2-5ms with ~95% recall). Increasing ef_search to 100 or 200 improves recall to 98-99.5% with a modest latency increase to 10-20ms.
The Senior Full-Stack Production Kit (2026)
Checklists, Docker recipes, and SSR error fixes in one dense PDF.