pgvector.app
  1. Home
  2. Tools
  3. Index planner
Tool · planning

Index planner & SQL generator

Recommendations come from indexes we built and measured — 6 HNSW configurations and 6 IVFFlat configurations on OpenAI embeddings — not from rules of thumb alone. Every number links back to its measurement.

Tested on pgvector 0.8.7 · PostgreSQL 18.6Updated 2026-10-27

Your data

Your queries

Your server

sqlGenerated for pgvector 0.8.7

    The URL updates as you type — bookmark or share it to keep a plan. Nothing is sent to a server.

    How the planner decides#

    1. Representation by dimension limit. Up to 2,000 dims: vector. 2,001–4,000: index embedding::halfvec(n). Up to 64,000: binary quantization with re-ranking. "Least memory" switches to halfvec from 512 dims, because in our test halfvec cost -0.2 points of recall for a 50% smaller index.
    2. Index type. HNSW unless you ask for the fastest build on static data, where IVFFlat built 9.0× faster in our test.
    3. Parameters from measured curves. For every (m, ef_construction, ef_search) we measured, the planner predicts recall at your row count — extrapolating how recall fell between 100K and 500K rows — and picks the lowest-latency setting that meets your target.
    4. Size and memory come from the storage model, which is checked against our real indexes; build memory from the "graph no longer fits" notice we measured.
    5. Build time scales our measured build by rows (fitted exponent 1.09 between 100K and 500K), dimensions and your core count.

    Always measure recall on your own data. Our curves come from OpenAI text-embedding-3-large on DBpedia. Other models and corpora cluster differently. The cheatsheet's recall query takes a minute to run.

    Frequently asked questions

    What ef_search should I use in pgvector?

    Start with the default of 40 and measure. On our 100K OpenAI-embedding benchmark it gave recall@10 of 0.947; 0.983 at 100 and 0.990 at 200, with median latency rising from 2.9 ms to 9.1 ms. ef_search must be at least your LIMIT.

    What are good HNSW m and ef_construction values?

    The defaults (m = 16, ef_construction = 64) are a sound start for 1,536-dim embeddings. Raise them only when you need recall above what ef_search alone can buy: in our tests m = 32 reached higher recall at the same latency but built 1.6× slower and was 1.0× the size.

    How many lists should an IVFFlat index have?

    The pgvector README suggests rows / 1000 up to 1M rows and √rows above that, with probes around √lists as a starting point. In our measurements the default probes = 1 is far too low: 316 lists at probes = 1 found only 55.0% of true neighbours.