Vertex AI Vector Search
Managed approximate nearest-neighbour index.
Problem it solves: Exact search over millions of vectors is too slow.
Where it sits: Queried by the retrieval service.
When to use
- Semantic retrieval for RAG and recommendations.
When not to use
- Small corpora where brute force is fine.
Failure modes
- Recall drops with aggressive ANN settings.
- Missing access-control filters leak documents.
Metrics to watch
- Query latency (ms)
- Recall@k
- QPS
Alternatives
- Hybrid keyword + vector search
Configuration in Labs (illustrative defaults)
- Capacity per instance (req/s) = 1000 — Maximum requests one instance completes per second before it saturates.
- Write capacity (primary) (writes/s) = 500 — Writes the single primary can absorb per shard. Replicas do not add write capacity.
- Read replicas (count) = 1 — Each replica adds one instance of read capacity. Replication lag is not modelled numerically.
- Shards (count) = 1 — Partitions; each multiplies read and write capacity assuming keys spread evenly (no hot key).
- Base service time (ms) = 20 — Processing time per request at zero load. Queueing adds to this as utilisation rises.
Vendor examples (pattern only): Google Cloud managed service. Simulated as a generic “Vector database”.