Hints

The write landed in a buffer or fresh segment that is not yet searchable; the index has a freshness lag between acknowledged write and queryable vector

The vector was silently rejected because its values were not normalized to unit length

ANN search is approximate, so a brand new vector has a permanently lower chance of being found

The query embedding model must be restarted before it can see new vectors

Query latency creeping upward over weeks while the live vector count stays roughly flat

Memory footprint refusing to shrink even after large delete jobs complete

Recall dipping for queries that land in heavily churned regions of the corpus

Write throughput climbing steadily as more vectors are deleted

Cosine scores turning negative for normalized embeddings after deletes

Serverless usage based pricing: pay per query and per GB stored, so the 23 idle hours cost almost nothing

Dedicated pods sized for 2,000 QPS, because peak capacity must be reserved around the clock

Self-hosted GPU cluster, since burst traffic always justifies GPU acceleration

Per seat licensing, because cost should track the number of engineers using the database

SPANN style: keep only centroids in RAM and fetch whole posting lists per query, a few large sequential reads that tolerate high latency storage well; graph designs like DiskANN need many dependent point reads, which object storage latency punishes

DiskANN style, because graph traversal minimizes total bytes read and byte count is all that matters on remote storage

Neither works: billion scale ANN fundamentally requires all vectors resident in RAM

Either works identically, since ANN algorithm choice is independent of the storage medium's access pattern

The rebuild competes for CPU, memory bandwidth, and page cache; queries that lose the contention race stall, which shows up in the tail while the median stays healthy

Reindexing temporarily converts the index to brute force, making every query proportionally slower

The new index has lower recall, and lower recall always manifests as higher latency

p99 metrics are unreliable during writes and should be ignored until the rebuild finishes

Verify the alarm itself: rerun the recall eval and check whether the ground truth set or eval corpus snapshot went stale

Inspect index health stats: tombstone ratio, segment counts, and any large bulk delete or ingest jobs that ran overnight

Audit config drift: did a managed service or library auto upgrade silently change default ef_search, nprobe, or quantization settings

Probe the embedding provider: re-embed a fixed sentence set and diff against stored vectors to detect a silent model version change behind the same API name

Rebuild or compact the index in staging from source data and compare recall to production to isolate index corruption or accumulated degradation

Build the index on GPU with CAGRA (cuVS), which cuts graph construction from hours to minutes, then serve it from CPU memory

Raise ef_search so queries compensate for the unfinished index

Switch the distance metric from cosine to dot product to speed up construction

Shrink the dataset by deleting the oldest half of the vectors before each rebuild

Provision Postgres with pgvector, create the table, choose the distance operator, and plan HNSW parameters to match production recall needs

Enable dual writes so every new upsert and delete is applied to both Pinecone and Postgres

Bulk export historical vectors plus metadata from Pinecone and COPY them into Postgres, then build the HNSW index

Shadow query both systems with mirrored production traffic and compare recall, latency, and result overlap

Shift read traffic to Postgres gradually behind a flag, watching error rates and tail latency

After a stable soak period, stop dual writes and decommission the Pinecone index

Thousands of mostly cold tenant indexes (agent memory, per customer document stores) queried sporadically, where paying RAM prices for idle vectors dominates the bill

A single hot index serving 20,000 QPS at a strict 10 ms p99, where every query must hit warm memory

A high frequency trading signal store where microseconds of latency decide profitability

A 50k-vector prototype, where infrastructure cost is irrelevant either way

Create a new collection for the new model's vectors, with its own dimension, metric, and index parameters

Start dual writes: every new and updated document is embedded with both models and written to both collections

Backfill the historical corpus into the new collection in rate limited, checkpointed batches

Shadow read: mirror a slice of live queries to the new collection and compare retrieval quality offline

Flip read traffic to the new collection behind a feature flag, keeping dual writes running so rollback is instant

After a stable soak period, stop dual writes, archive or drop the old collection, and retire the old model