Amazon Aurora PostgreSQL with pgvector gives teams a vector-search path inside a relational database they may already operate. In 2026, AWS guidance for production pgvector workloads emphasizes HNSW for most online retrieval, IVFFlat for selected memory-sensitive or build-cost scenarios, and no approximate index at all for small datasets or cases where exact recall is more important than latency. The right choice is a recall, latency, memory, and write-pattern decision\u2014not simply \u201ccreate a vector index.\u201d<\/p>\n
Within Generative AI on AWS<\/a>, Aurora pgvector is especially useful when embeddings need to live close to relational attributes used for filtering, joins, authorization, or application state. The existing Aurora architecture<\/a> article provides the database operational context.<\/p>\n The planned Vector Search with Aurora PostgreSQL<\/a> article goes broader into query design. This page focuses on index behavior and production maintenance.<\/p>\n pgvector can compute exact nearest-neighbor search without an ANN index. That scans the relevant vectors and provides the recall baseline. Approximate indexes such as HNSW and IVFFlat trade some recall for lower query cost and latency.<\/p>\n Teams should measure approximate retrieval against exact results on representative queries. Without that baseline, it is easy to celebrate a fast query that consistently misses the documents users actually need.<\/p>\n Small datasets may not need an ANN index at all. An exact scan can be operationally simpler and provide perfect recall when the corpus is small enough for the target latency.<\/p>\n HNSW builds a multi-layer graph of neighboring vectors. Search navigates that graph rather than comparing the query with every row. AWS\u2019s current production guidance describes HNSW as the default choice for most pgvector workloads because it usually provides strong recall and low latency once the index is built.<\/p>\n The trade-off is memory and build cost. HNSW stores graph structure in addition to the vectors, and high-quality index construction can require significant memory. Write-heavy workloads also have to maintain the graph as vectors are inserted or deleted.<\/p>\n Capacity planning should therefore include the index, not only the table. A vector table that fits comfortably in the database can still have an HNSW index large enough to pressure memory.<\/p>\n IVFFlat groups vectors into clusters and searches selected clusters at query time. The index is generally cheaper to build and uses less memory than HNSW because it does not maintain the same graph structure.<\/p>\n It also has different tuning behavior and can be more sensitive to data distribution and the number of probed lists. Teams should benchmark it instead of assuming \u201clighter index\u201d automatically means better production economics.<\/p>\n A workload with infrequent index rebuilds and strict latency may favor HNSW; a memory-constrained or frequently rebuilt environment may justify evaluating IVFFlat.<\/p>\n Many enterprise queries apply metadata filters such as tenant, region, document type, or security classification before ranking vectors. Approximate indexes can return too few candidates after filtering if the ANN search explores vectors that are later removed by the filter.<\/p>\n pgvector 0.8.0 introduced iterative scanning improvements that help retrieve additional candidates when filters reduce the result set. Partitioning and appropriate relational indexes can also reduce the candidate space for highly selective filters.<\/p>\n Filtered recall should be tested separately from unfiltered recall. A retrieval system can look excellent on global nearest-neighbor benchmarks and fail badly when every production request includes a tenant filter.<\/p>\n pgvector supports distance operators for cosine distance, inner product, Euclidean distance, and other vector representations. The index operator class must align with the distance function the query uses.<\/p>\n The embedding model\u2019s guidance should determine the metric. If the model expects cosine similarity, building an index for a different distance can change ranking quality even though the SQL executes correctly.<\/p>\n Embedding changes should be treated like schema changes. Moving from one model or dimension to another usually requires re-embedding data and rebuilding the index rather than mixing incomparable vectors.<\/p>\n Large HNSW builds can consume substantial memory and take meaningful time. AWS recommends planning memory headroom and monitoring the index size as the corpus grows. A production migration should not discover during the build that the index no longer fits comfortably in memory.<\/p>\n Long-running vector stores also experience churn. Updates and deletes can leave the index less efficient over time, and maintenance operations may be required to restore performance. Teams should monitor index size, query latency, buffer-cache behavior, and write patterns rather than treating the initial build as the end of the indexing lifecycle.<\/p>\n A growth forecast should include vector count, dimension, index overhead, and expected retention.<\/p>\n AWS\u2019s 2026 Aurora guidance describes binary quantization with reranking as one option for very large pgvector datasets that no longer fit comfortably in memory. The compressed index can reduce memory pressure, while the final candidates are reranked using higher-precision vectors.<\/p>\n This introduces a new recall trade-off. Candidates that never make it through the quantized first stage cannot be recovered by reranking. The organization should therefore benchmark quantized recall against the non-quantized baseline before using the technique for high-value retrieval.<\/p>\n Quantization is a scaling tool, not a universal default for every vector table.<\/p>\n A vector index solves similarity search. It does not replace ordinary PostgreSQL indexes for tenant filters, dates, status columns, or keyword search. Bedrock Knowledge Bases guidance for Aurora includes HNSW plus indexes for text and metadata because real retrieval often combines semantic similarity with structured filtering.<\/p>\nExact search is the baseline every approximate index should be compared against<\/h3>\n
HNSW is the default production choice for many Aurora workloads<\/h3>\n
IVFFlat can be attractive when build cost and memory matter more<\/h3>\n
Filtered vector search changes the recall problem<\/h3>\n
Distance operator must match the embedding model and retrieval design<\/h3>\n
HNSW build and maintenance need memory headroom<\/h3>\n
Quantization can extend HNSW scale when the index outgrows memory<\/h3>\n
Metadata indexes and full-text indexes still matter in hybrid retrieval<\/h3>\n