Two releases this week point at the same conclusion. Databricks put Lakebase Search into general availability on AWS and Azure on September 28 — an ANN vector index and a BM25 full-text index delivered as two Postgres extensions. On September 30 Perplexity shipped pplx-embed-v2-context, a contextual embedding model that encodes a whole document in one pass with native INT8 and binary quantization built in.
Read together, they show where retrieval quality and cost actually come from. Quality comes from fusion — combining a lexical path with the vector path. Cost comes from quantization — storing and scanning far fewer bits per vector. Neither is the lever most teams reach for first.
Two published numbers that settle the argument
The cleanest comparison this month is AWS’s vector store analysis for Bedrock Knowledge Bases, published September 17. Two findings matter.
First, hybrid search gives a consistent lift over semantic-only search — roughly 6% better NDCG on their benchmark across both full-precision and compressed indexes. Fusion is the reliable part of the quality curve.
Second, a 1,024-dimension index stored as binary vectors with hybrid search scored an NDCG of 0.3658, while the same index stored as float with semantic-only search scored 0.3633. The compressed index with fusion beat the uncompressed index without it, at roughly 13x less memory — 0.40 GiB against 5.34 GiB. Binarization has a quality cost; BM25 fusion more than pays it back.
If your roadmap includes “migrate to a better embedding model,” the evidence says the cheaper move wins first. Turn on the keyword path before you pay for anything else.
Quantization is where the bill lives
Databricks’ write-up names the mechanism behind surprise database bills. pgvector keeps its HNSW graph in memory to stay fast; when that graph spills to disk, queries turn into chains of random reads and latency degrades by 10x to 50x. The fix is not a bigger instance. It is an index that does not need to be memory-resident.
Their architecture decouples storage from compute, groups vectors with hierarchical IVF clustering, and compresses each vector to roughly one bit per dimension with RaBitQ binary quantization, then re-ranks a shortlist at full precision. On VectorDBBench’s 100M-vector LAION set, they report 2x the throughput of the next-best system, 4x lower cost than cloud Postgres with pgvector, and 97% recall at 71 ms P99 — with 100M vectors servable on a single compute unit.
At a much larger scale, Kwai’s production write-up on Apache Doris (September 30) proves this scales to petabyte workloads. One hundred billion 2,048-dimension vectors went from 42 minutes per query under brute-force search to 21 seconds using an on-disk IVF index plus 4-bit RaBitQ at 8x compression, with recall@100 of 0.982.
Their benchmark carries an important caveat: quantization choices are dimension-dependent. At 128 dimensions, product quantization beat 1-bit RaBitQ (0.633 versus 0.453 recall@100). At 2,048 dimensions the ranking reversed (0.897 for RaBitQ versus 0.771 for PQ). “Use binary vectors” is not a global rule — it is a measurement you run on your own corpus.
Perplexity’s new model reinforces the trend by building native INT8 and binary quantization directly into the weights for up to 32x storage savings. Storage efficiency is becoming a property of the model layer, not just database tuning.
Fusion fixes the queries that fail
Instaclustr’s Cassandra vector search walkthrough (September 23) demonstrates the primary failure mode. Asked for recall notice 24V-330, approximate nearest-neighbour search ranked the correct document ninth, at a similarity of 0.7332 — below eight notices that never mention it. Recall notices share sentence structure; a short identifier is a tiny fraction of the embedding. Cosine distance has no concept of an exact token match.
This is not a Cassandra defect. Pinecone, pgvector and OpenSearch kNN produce the same ordering, and no embedding model upgrade fixes it. A lexical path beside the vector path does, combined with SQL filter predicates. Databricks shipped a BM25 extension for this exact reason — standard Postgres tsvector lacks corpus-wide inverse document frequency, so rare high-intent terms do not get proper weight.
What database platforms just told us
General-purpose databases are absorbing vector search. Databricks bundles ANN and BM25 behind one SQL call. Elastic announced a serverless vector database with automatic chunking, embedding, and reciprocal rank fusion. Cassandra 5.0 added native vector columns and ANN in CQL. AWS positions S3 Vectors as a low-cost storage tier beneath OpenSearch.
Telemetry confirms adoption. Datadog’s State of Postgres report shows pgvector usage grew 24% between December 2025 and May 2026, making it the fastest-growing non-bundled extension.
The order of operations
Instead of jumping to a model migration, execute this sequence — each step cheaper than the next:
- Measure first. Build a labelled query set and track recall@k and p95 latency separately.
- Quantize the index. Store compressed vectors, then re-rank a bounded shortlist at full precision. This is the largest memory win.
- Add the lexical path. Fuse BM25 or full-text search with vector queries using reciprocal rank fusion.
- Add a reranker after fusion. Re-ranking a fused shortlist yields real gains; re-ranking a poor retrieval set just reorders wrong documents.
- Change the embedding model last. It is the most expensive step and forces a complete corpus re-embedding.
What this means for agencies and teams
Retrieval is now a data pipeline problem rather than a model problem. Clear deliverables — a labelled query set, measured quantization and fusion benchmarks, and a cost model per thousand queries — give clients predictable ROI.
The scale threshold required to justify a separate vector database is higher than ever. Check your production retrieval failures this week: if bad results stem from identifiers or exact terms, an embedding upgrade will not help. Turning on fusion will.