About qdrant-scaling
A Qdrant scaling skill that routes common capacity and performance symptoms to focused guidance on data volume, throughput, latency, and query size. It helps teams choose the relevant scaling approach and avoid settings that worsen the reported bottleneck.
Key features
- 01Symptom-based routing
- 02Data-volume scaling guidance
- 03Throughput and latency guidance
- 04Large-result query guidance
- 05Tenant and time-window strategies
Use cases
- 01Planning shards as data grows
- 02Improving query throughput or tail latency
- 03Handling large result sets
- 04Scaling tenant or time-limited data
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/qdrant-scalingin Claude Code to confirm it loaded.
Details
From the project READMEQdrant Scaling
Route first, then answer. Match the user's symptom in the table, Read that file, and answer from it.
Do not answer from this page alone: it contains routing only, not the guidance. If two rows match, read both.
| The user says | Read |
|---|---|
| Data does not fit on a single node, running out of disk or memory as the dataset grows | scaling-data-volume/SKILL.md |
| Need to shard the collection across more nodes, data outgrew one node | scaling-data-volume/SKILL.md |
| Cannot handle enough parallel queries, need higher QPS or throughput | scaling-qps/SKILL.md |
| Can't hold the request rate, CPU is pegged | scaling-qps/SKILL.md |
| A single query is too slow, need to cut the tail latency of individual requests | minimize-latency/SKILL.md |
| p99 or tail latency too high, but traffic/QPS is fine | minimize-latency/SKILL.md |
| Queries return very large result sets and slow down | scaling-query-volume/SKILL.md |
Large limit, top-1000 queries, pagination, scroll across shards | scaling-query-volume/SKILL.md |
| Many tenants or customers, one collection each, tenant isolation | scaling-data-volume/tenant-scaling/SKILL.md |
| Only recent data matters, retention, expiring old vectors, time-based rotation | scaling-data-volume/sliding-time-window/SKILL.md |
| Single node no longer fits the workload, before deciding to shard | scaling-data-volume/vertical-scaling/SKILL.md |
| Already vertically maxed out, need more nodes, resharding | scaling-data-volume/horizontal-scaling/SKILL.md |
Latency and throughput pull opposite ways on segment count.
For latency, increase segments toward the CPU core count (default_segment_number: 16).
For throughput, use fewer and larger segments (default_segment_number: 2).
Applying the wrong direction makes the reported problem worse.