Sharding partitions points across nodes; default is hash on point ID
Sharding is horizontal partitioning of a collection across multiple shards, each of which can live on a different node and can have its own replicas. Each shard holds a subset of the collection's points and maintains its own segments, WAL, indexes, and optimizer state. A distributed collection is therefore a set of shards plus a coordinator layer that routes requests and merges results. Sharding exists for two reasons: to scale storage beyond what one node can hold, and to scale query throughput by parallelizing search across shards. In Qdrant, shard_number and replication_factor are set at collection creation, and each shard is placed on a node by the cluster's placement logic.
By default, a point is assigned to a shard by hashing its point ID and mapping the hash modulo the shard count. This is the auto sharding strategy. The client does not choose the shard - it just upserts a point with an ID, and the cluster computes the target shard from the hash. The consequence is that points are spread roughly evenly across shards regardless of their content, which is good for load balance but means that a query with no shard key must fan out to every shard. Each shard runs its local search and returns its top-k, and the coordinator merges the per-shard results into a global top-k. This fan-out is the main cost of sharding: latency is bounded by the slowest shard, and the coordinator does more work as shard count grows. Hash-based sharding is the right default when you do not have a natural partition key and when queries are not scoped to a subset of the data, because it gives even distribution and simple routing.
shard_number: number of shards in the collection, set at creation and not trivially changeable afterward.
replication_factor: number of replicas per shard, for fault tolerance and read scaling.
Default routing: point ID is hashed and mapped to a shard; the client has no control.
Query fan-out: a query without a shard key hits every shard; the coordinator merges the results.
Replicas: each shard has a primary that accepts writes and replicas that serve reads and provide failover.
The trade-off is even distribution and simple routing against fan-out cost and lack of data locality. Hash sharding gives even load but no locality, so every unscoped query pays the full fan-out. The alternative is custom sharding, where you choose a shard key and points are routed by that key, which lets scoped queries hit a single shard. The common mistake is confusing shards with replicas. Shards partition data; replicas duplicate a shard for fault tolerance and read scaling. Increasing shard_number increases parallelism but also increases fan-out, so more shards is not automatically better. The second common mistake is assuming you can change shard_number on an existing collection as easily as you change an optimizer threshold. It requires re-sharding, which is effectively a migration. The third mistake is sizing shards by point count alone - a shard's cost is driven by vector count, graph size, and payload index size, not just the number of points. Version note: the default sharding strategy and the exact hashing (modulo versus consistent hashing) have changed across releases, so if you are reasoning about which shard a specific ID lands on, verify against your version rather than assuming a stable mapping.
Version-dependent: the shard placement logic, the exact hashing function, and the ability to change shard_number after creation have evolved. In newer releases, some of this is exposed through the cluster API and the sharding_method field. The write_consistency_factor and replication_factor semantics have also changed across versions. If you are designing a cluster and need to reason about shard placement or rebalancing, read the release notes for your version and inspect the actual shard layout at runtime rather than relying on an older mental model.
0-2 years experience
2-5 years experience
5-8 years experience
8+ years experience
