Best for
- Use when someone asks 'vertical or horizontal?
Source profileQuality 69/100
github/awesome-copilot/skills/qdrant-scaling/scaling-data-volume/horizontal-scaling/SKILL.md
qdrant-horizontal-scaling
Diagnoses and guides Qdrant horizontal scaling decisions. Use when someone asks 'vertical or horizontal?', 'how many nodes?', 'how many shards?', 'how to add nodes', 'resharding', 'data doesn't fit', or 'need more capacity'. Also use when data growth outpaces current deployment.
- Source repository stars
- 37,126
- Declared platforms
- 0
- Static risk flags
- 0
- Last source update
- 2026-07-28
- Source checked
- 2026-07-28
Decision brief
What it does—and where it fits
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 IOP…
Not for
- Tasks that require unconfirmed production actions or broad system permissions.
- Environments where the pinned source and install steps cannot be inspected.
Compatibility matrix
Platform support, with evidence labels
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
Inspect first. Install second.
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
Source-detected install commandSource
npx skills add https://github.com/github/awesome-copilot --skill "skills/qdrant-scaling/scaling-data-volume/horizontal-scaling"Safe inspection promptEditorial
Inspect the Agent Skill "qdrant-horizontal-scaling" from https://github.com/github/awesome-copilot/blob/9933dcad5be5caeb288cebcd370eeeb2fc2f1685/skills/qdrant-scaling/scaling-data-volume/horizontal-scaling/SKILL.md at commit 9933dcad5be5caeb288cebcd370eeeb2fc2f1685. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
What the source asks the agent to do
- 01
Most basic distributed configuration
Minimum 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. Thi…
3 nodes, 3 shards with replicationfactor: 2 for zero-downtime scaling- 3 nodes, 3 shards with replicationfactor: 2 for zero-downtime scalingMinimum 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… - 02
Choosing number of shards
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.
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. - 03
Changing number of shards
Use when: shard count isn't evenly divisible by node count, causing uneven distribution, or need to rebalance.
Available in Qdrant Cloud ReshardingResharding is not available for self-hosted deployments.Use when: shard count isn't evenly divisible by node count, causing uneven distribution, or need to rebalance. - 04
What NOT to Do
Do not jump to horizontal before exhausting vertical (adds complexity for no gain)
Do not jump to horizontal before exhausting vertical (adds complexity for no gain)Do not set shardnumber that isn't a multiple of node count (uneven distribution)Do not use replicationfactor: 1 in production if you need fault tolerance
Permission review
Static risk signals and limitations
No configured static risk pattern was detected
This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.
Evidence record
Why each signal appears
EvidenceSourceComputedTestedEditorial
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 69/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 37,126 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
Provenance and original SKILL.md
- Repository
- github/awesome-copilot
- Skill path
- skills/qdrant-scaling/scaling-data-volume/horizontal-scaling/SKILL.md
- Commit
- 9933dcad5be5caeb288cebcd370eeeb2fc2f1685
- License
- MIT
- Collected
- 2026-07-28
- Default branch
- main
View the original SKILL.md
What to Do When Qdrant Needs More Capacity
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).
Most basic distributed configuration
- 3 nodes, 3 shards with
replication_factor: 2for zero-downtime scaling
Minimum 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.
Choosing number of shards
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.
Changing number of shards
Use when: shard count isn't evenly divisible by node count, causing uneven distribution, or need to rebalance.
Resharding is expensive and time-consuming, it should be used as a last resort if regular data distribution is not possible. Resharding is designed to be transparent for user operations, updates and searches should still work during resharding with some small performance impact.
But resharding operation itself is time-consuming and requires to move large amounts of data between nodes.
- Available in Qdrant Cloud Resharding
- Resharding is not available for self-hosted deployments.
Better alternatives: over-provision shards initially, or spin up new cluster with correct config and migrate data.
What NOT to Do
- Do not jump to horizontal before exhausting vertical (adds complexity for no gain)
- Do not set
shard_numberthat isn't a multiple of node count (uneven distribution) - Do not use
replication_factor: 1in production if you need fault tolerance - Do not add nodes without rebalancing shards (use shard move API to redistribute)
- Do not scale down RAM without load testing (cache eviction causes days-long latency incidents)
- Do not hit the collection limit by using one collection per tenant (use payload partitioning)
Alternatives
Compare before choosing
Computed 9737,126
github/awesome-copilot
geofeed-tuner
Use this skill whenever the user mentions IP geolocation feeds, RFC 8805, geofeeds, or wants help creating, tuning, validating, or publishing a self-published IP geolocation feed in CSV format. Intended user audience is a network operator, ISP, mobile carrier, cloud provider, hosting company, IXP, or satellite provider asking about IP geolocation accuracy, or geofeed authoring best practices. Helps create, refine, and improve CSV-format IP geolocation feeds with opinionated recommendations beyon
Computed 967
event4u-app/agent-config
laravel-horizon
Use when working with Laravel queues in production — Horizon dashboard, worker supervision, job metrics, balancing strategies — even when the user just says 'my jobs are piling up'.
Computed 95234,327
affaan-m/ECC
mle-workflow
Production machine-learning engineering workflow for data contracts, reproducible training, model evaluation, deployment, monitoring, and rollback. Use when building, reviewing, or hardening ML systems beyond one-off notebooks.
Computed 9531,966
K-Dense-AI/scientific-agent-skills
simpy
Build, inspect, test, and analyze bounded process-based discrete-event simulations with SimPy, including events, resources, interrupts, monitoring, replications, warm-up, and reproducible output analysis.