AWS Benchmarks Show 9.4x Faster Pgvector Queries With New Scans

Teams at Discourse run pgvector inside thousands of PostgreSQL databases. The extension drives related topic suggestions, tag recommendations, augmented search results, and retrieval-augmented generation for file analysis. These features serve billions of page views each month without separate infrastructure.

Engineers there apply aggressive quantization. They store embeddings as half-precision 16-bit floats to cut memory use. Binary vector indexing speeds up similarity checks while keeping accuracy high enough for user-facing features. This setup lets a single platform host vector search for every customer instance.

Earlier pgvector releases applied filters after approximate index scans. Results often vanished when filters removed too many candidates before final checks. Version 0.8.0 introduced iterative scans that rescan the index automatically until enough matches pass all conditions.

Two modes exist. Strict mode preserves exact distance ordering. Relaxed mode accepts minor reordering for faster execution in cases like product recommendations where precise ranks matter less. AWS Aurora tests on complex filtered queries dropped average latency from 123.3 milliseconds to 13.1 milliseconds, a 9.4 times improvement.

Creating HNSW indexes on datasets with millions of vectors spikes RAM usage. Builds routinely need 10 gigabytes or more and run for hours. PostgreSQL allocates this space through the maintenance work mem parameter, so teams schedule operations during low-traffic windows to avoid crashes.

Discourse handles the challenge by partitioning workloads and monitoring memory closely. Smaller teams without dedicated database staff face steeper hurdles. Over-provisioning instances becomes necessary, raising cloud costs compared to purpose-built vector stores that manage memory internally.

PostgreSQL treats vector operations like any other index access. The cost-based planner lacks models tuned for approximate nearest-neighbor behavior. Developers adjust parameters such as hnsw dot ef search and ivfflat dot probes per query to balance recall and speed.

Legal document analysis platforms combine vector similarity with metadata filters. Tuning ef search values prevents slow scans when filters eliminate most candidates early. E-commerce recommendation engines set lower probes for real-time responses under moderate traffic. Each workload needs testing to find stable settings.

PostgreSQL page size caps standard vectors at 2,000 dimensions. Half-precision raises the ceiling to 4,000. Many models on HuggingFace produce longer embeddings, pushing teams toward dimensionality reduction or binary quantization. Accuracy drops slightly but often stays acceptable for search tasks.

Academic paper retrieval systems reduce dimensions with PCA before storage. Product catalogs use subvector indexing to split high-dimensional embeddings across columns. Both approaches add preprocessing steps yet keep everything inside one database.

Storing embeddings alongside relational rows enables ACID transactions and SQL joins. Teams avoid synchronization code between systems. Backups, replication, and security policies apply uniformly. Organizations already running PostgreSQL reuse existing skills and tools.

Startups with limited staff sometimes pay more in engineering time than managed vector database fees. Enterprises with database teams report 60 to 80 percent savings for workloads under 100 million vectors when factoring total ownership costs. The break-even point depends on dataset size and query complexity.

Discourse shows quantization and binary indexing let pgvector serve massive traffic on shared infrastructure. Their playbook includes regular index maintenance and relaxed ordering for non-critical rankings.

Law firms store case documents with dense embeddings for similarity search. Batch processing tolerates longer query times, so strict mode ensures precise result ordering. Combining full-text and vector filters through application logic delivers hybrid retrieval without extra systems. Both cases highlight the value of deep PostgreSQL knowledge for stable production use.