The “Coordinator” node’s role in a distributed query
In a sharded vector database, the coordinator is the node that receives the client query, decides which shards to contact, sends the vector search (and optional filters) to those shards, and merges the returned candidates into a single ranked result.
Summary
- In a sharded VDB, the coordinator receives the client query, decides which shards to contact, sends the vector search (and optional filters) to those shards, and merges returned candidates into a single ranked result.
- Coordinator holds metadata (which shard has which partition, topology), not bulk data. For k-NN it may fan out to all shards or only relevant ones (e.g. spatial sharding); merges and re-ranks (e.g. by distance or RRF) and returns final top-k.
- Can be stateless or dedicated; single point of latency aggregation. Load balancing and rate limiting often applied at coordinator layer. Pipeline: receive query, select shards, fan out, collect top-k per shard, merge and re-rank, return final top-k. Practical tip: use stateless coordinators so load balancing works; monitor coordinator latency.
What the coordinator does
The coordinator does not typically hold the bulk of the data; it holds metadata (which shard has which partition, cluster topology) and implements the query protocol. For a k-NN query, it may fan out to all shards or only to shards that can contain relevant vectors (e.g. with spatial sharding). Each shard returns its top-k (or more) candidates; the coordinator then merges and re-ranks (e.g. by distance or RRF) and returns the final top-k to the client.
Coordinator design and load
Coordinators can be stateless (any node can coordinate) or dedicated. They are a single point of latency aggregation and can become a bottleneck, so load balancing and rate limiting are often applied at the coordinator layer. In some designs, clients talk directly to shards for simple key lookups while using the coordinator only for vector search.
Pipeline: receive query from client, select shards (all for ID sharding or nearest for spatial), fan out vector search and filters to those shards, collect top-k (or more) per shard, merge and re-rank (e.g. by distance or RRF), return final top-k to client. Practical tip: use stateless coordinators so load balancing works; monitor coordinator latency and consider dedicated coordinators if they become a bottleneck.
Frequently Asked Questions
What is the coordinator in a sharded VDB?
The node that receives the client query, decides which shards to contact, sends the vector search (and optional filters) to those shards, and merges the returned candidates into a single ranked result. It holds metadata, not the bulk of the data.
How does the coordinator merge results?
Each shard returns its top-k (or more) candidates; the coordinator merges and re-ranks (e.g. by distance or RRF) and returns the final top-k to the client. With spatial sharding, it may contact only relevant shards.
Can the coordinator be a bottleneck?
Yes. It is a single point of latency aggregation. Load balancing and rate limiting are often applied at the coordinator layer. Coordinators can be stateless (any node can coordinate) or dedicated.
Do clients always talk to the coordinator?
In some designs, clients talk directly to shards for simple key lookups and use the coordinator only for vector search. Depends on the VDB architecture. See scaling and sharding.