pgvector 0.7 and Beyond: What Changed for Production Vector Search
If you built your vector search setup on an early pgvector release and have not looked at it since, the extension you are running today behaves differently. Index build times dropped, query accuracy under load improved, and the defaults that made sense two years ago are no longer the right starting point. This is a guide to what actually changed and what to configure if you are running pgvector performance-critical workloads on PostgreSQL in 2026.
We work with a lot of teams building production RAG systems on Symfony and Next.js backends, and pgvector tuning is one of the most common things we get called in to fix. Usually the index was built once with default settings and never touched again, even as the table grew past a million rows.
HNSW parameters: ef_construction and m are not "set and forget"
HNSW (Hierarchical Navigable Small World) is now the default recommendation over IVFFlat for most production workloads, but the two parameters that control its behavior, ef_construction and m, get left at their defaults far too often.
m controls how many bidirectional links each node keeps in the graph. Higher values improve recall but increase both index size and build time. ef_construction controls how thorough the search is while the index is being built, which trades build time for the quality of the graph structure. The relationship between the two is not linear: doubling m from 16 to 32 typically adds noticeably more memory overhead than doubling ef_construction from 64 to 128, for a similar recall gain.
A rough starting point we have found useful: for tables under five million rows with moderate recall requirements, m = 16 and ef_construction = 64 still hold up well. Past that size, or when recall matters more than build speed, moving to m = 24 and ef_construction = 100 closes a meaningful accuracy gap without doubling your index size. The only way to know for your data is to test both settings against your own query distribution, not a synthetic benchmark.
Parallel index builds change the math for large tables
Building an HNSW index used to be a single-threaded process, which meant that reindexing a table with tens of millions of rows could take hours. Parallel index build support changes that calculus: on a machine with enough CPU cores, build time drops substantially, and the wall-clock cost of experimenting with different m and ef_construction values goes from "plan a maintenance window" to "run it during the day."
This matters more than it sounds like on paper. Teams that used to leave a bad index configuration in place because rebuilding was too disruptive can now treat index tuning as an iterative process. If you have not rebuilt your vector index in the last year, the parallel build support alone is a reason to test whether a better configuration is now cheap enough to adopt.
Sparse vectors and hybrid search
Dense embeddings are good at capturing semantic similarity but weak at exact keyword matches, which is a real problem for product names, error codes, or anything a user might search for verbatim. Sparse vector support in recent pgvector releases makes it practical to combine dense and sparse representations in the same query without bolting on a separate search engine.
The pattern we recommend: run a dense vector search for semantic relevance and a sparse (or full-text) search for exact term matches, then combine the two result sets with a reciprocal rank fusion step in your application layer. This gets you most of what a dedicated hybrid search product offers, without adding Elasticsearch or a similar system to your infrastructure just to handle a subset of queries.
Choosing the right distance function
pgvector supports cosine distance, L2 (Euclidean) distance, and inner product, and the choice is not cosmetic. Cosine distance is the right default for most embedding models, since it measures the angle between vectors rather than their magnitude, which matches how most embedding models are trained. L2 distance is appropriate when the magnitude of the vector carries real information, which is rare for text embeddings but common in some computer vision use cases. Inner product is fastest to compute and is the right choice when your embeddings are already normalized, since normalized inner product and cosine distance produce the same ranking.
Mixing distance functions across queries against the same index is a common source of bad results that gets misdiagnosed as a model problem. Check what your embedding model expects before you pick the index type, not after you notice recall is worse than it should be.
IVFFlat under concurrent writes
IVFFlat still has a place, mainly for smaller tables where the build cost of HNSW is not worth it, but its behavior under concurrent writes deserves a closer look than most teams give it. IVFFlat partitions vectors into lists based on a training step run at index creation time. Heavy write activity after that point does not automatically rebalance those lists, so a table that grows or shifts in distribution after the index was built can see recall degrade over months without any error or warning.
If you are running IVFFlat on a table with meaningful write volume, put a periodic reindex on your maintenance schedule rather than assuming the index stays accurate indefinitely. This is one of the more common silent failure modes we see in code audits: a search feature slowly getting worse while every metric that is actually being monitored, like p99 latency, looks fine.
Storage overhead: what you are actually paying for
HNSW indexes carry meaningfully more storage overhead than IVFFlat, since every vector needs to store its graph connections in addition to the raw vector data. The overhead scales with both vector dimension and the m parameter. For a table of 1536-dimension embeddings, which is what you get from many common embedding models, the HNSW index can add 60 to 100 percent on top of the raw vector storage, depending on your m setting. That is a real cost on a large table and worth factoring into capacity planning before you commit to a configuration, not after your database starts running out of disk.
A benchmark methodology that actually tells you something
Most public pgvector benchmarks use synthetic data with a uniform distribution and a query pattern that does not resemble how real applications query vector data. That produces numbers that look great in a blog post and mean very little for your workload.
A benchmark worth trusting needs three things: your own data, or a sample that preserves its real distribution and clustering; query patterns pulled from actual application logs rather than random vectors; and hardware that matches what you will run in production, since HNSW performance is sensitive to available memory and how much of the index fits in cache. Run the same query set against a few candidate configurations, measure recall against a ground truth set you trust, and measure p95 and p99 latency under a realistic concurrent load, not a single-threaded loop.
Where this leaves you in 2026
If you are on an older pgvector version, upgrading and moving from IVFFlat to HNSW is worth the effort for nearly every production use case we have looked at recently. Take advantage of parallel index builds to actually test configurations instead of guessing, get your distance function matched to your embedding model, and if you still need IVFFlat somewhere, put a reindex schedule on it.
This is the kind of tuning work that pays off quietly. Nobody notices when vector search recall is good. They notice when it is not, usually right after a customer complains that search stopped finding the obvious result.
If your team is building or scaling a production RAG system on PostgreSQL and wants a second set of eyes on the architecture, our code quality consulting work covers exactly this kind of performance and configuration review. For teams building the surrounding application from scratch, custom software development is where we usually start. Reach out at hello@wolf-tech.io or find more of our work at wolf-tech.io.