Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →qdrant/qdrant-horizontal-scaling
Diagnoses and guides Qdrant horizontal scaling decisions.
Passed 20 of 22 test cases with the skill, and 17 of 22 without it.
and 5 more in the full report
5 fixed15 passed either way0 still failing2 broke
Tokens, turns and time describe resource use, not a dollar price.
This benchmark measured an earlier version of the skill.
A newer attempt on gemini-3.6-flash on 10/11/2026 did not produce a publishable comparison (not comparable). The snapshot above is the previously measured run.
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
We're running a Qdrant deployment that is starting to hit resource limits with our expanding vector dataset. Could you explain whether we should upgrade our current machine or switch to a distributed setup, and if we transition to multiple nodes, what setup and replication settings do you recommend to ensure high availability?
| Checked | Without skill | With skill |
|---|---|---|
| Recommends upgrading single-node capacity (vertical scaling) before scaling horizontally. | Passed | Passed |
| Recommends a minimum of 3 nodes with replication_factor: 2 for high availability. | Missed | Passed |
| Recommends 6 to 12 total shards (2 to 4 shards per node) for a 3 to 6 node cluster. | Missed | Passed |
The instructions your model reads when the skill loads.
Vertical first: simpler operations, no network overhead, good up to ~100M vectors per node depending on dimensions and quantization. Horizontal when: data exceeds single node capacity, need fault tolerance, need to isolate tenants, or IOPS-bound (more nodes = more independent IOPS).
replication_factor: 2 for zero-downtime scaling, and at least 2 shards per node (6 shards) so you can add nodes later without resharding ShardingMinimum of 3 nodes is important for consensus and fault tolerance. With 3 nodes, you can lose 1 node without downtime. With 2 nodes, losing 1 node causes downtime for collection operations.
Replication factor of 2 means each shard has 1 replica, so you have 2 copies of data. This allows for zero-downtime scaling and maintenance. With replication_factor: 1, zero-downtime is not guaranteed even for point-level operations, and cluster maintenance requires downtime.
Shards are the unit of data distribution. More shards allows more nodes and better distribution, but adds overhead. Fewer shards reduces overhead but limits horizontal scaling.
For cluster of 3-6 nodes the recommended shard count is 6-12. This allows for 2-4 shards per node, which balances distribution and overhead.
Use when: shard count isn't evenly divisible by node count, causing uneven distribution, or need to rebalance.
Resharding is expensive and time-consuming, so use it as a last resort if regular data distribution is not possible. The collection stays available during resharding, with slightly reduced performance, but a lot of data moves between nodes Resharding.
Better alternatives: over-provision shards initially, or spin up new cluster with correct config and migrate data.
shard_number that isn't a multiple of node count (uneven distribution)replication_factor: 1 in production if you need fault tolerancetest cases passed, vs 17 / 22 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.