How does Weaviate decide which shard(s) to query for a given request?

For a collection split across multiple shards, an unfiltered vector or hybrid search generally needs to query every shard, since the globally best-matching objects could in principle live on any of them, and Weaviate fans the request out accordingly, merging the per-shard results into one final ranked list, similar in spirit to how other distributed vector databases handle cross-shard search.

Multi-tenant collections are a notable exception to this fan-out pattern: because each tenant's data is physically isolated in its own dedicated segment (effectively acting as its own shard boundary), a tenant-scoped query only ever needs to touch that specific tenant's segment, skipping every other tenant's data entirely rather than needing to fan out across the whole collection's shards. This is part of why multi-tenant queries in Weaviate can remain fast even as the total number of tenants (and total collection size) grows very large, since a given query's cost stays tied to one tenant's data volume rather than the collection's aggregate size.

For non-multi-tenant collections that still need to avoid unnecessary shard fan-out, applying property-based filters that a shard-routing strategy can use to skip clearly irrelevant shards (where supported) is the general technique for narrowing which shards actually need to be queried for a given request, though the degree to which this is possible depends on how the sharding key relates to the filtered property.