Best for
- Use when someone asks 'how to increase QPS', 'need more throughput', 'queries per second too low', 'batch search', 'read replicas', or 'how to handle more concurrent queries'.
Source profileQuality 69/100
github/awesome-copilot/skills/qdrant-scaling/scaling-qps/SKILL.md
qdrant-scaling-qps
Guides Qdrant query throughput (QPS) scaling. Use when someone asks 'how to increase QPS', 'need more throughput', 'queries per second too low', 'batch search', 'read replicas', or 'how to handle more concurrent queries'.
- Source repository stars
- 37,126
- Declared platforms
- 0
- Static risk flags
- 1
- Last source update
- 2026-07-28
- Source checked
- 2026-07-28
Decision brief
What it does—and where it fits
Throughput scaling means handling more parallel queries per second. This is different from latency - throughput and latency are opposite tuning directions and cannot be optimized simultaneously on the same node.
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-qps"Safe inspection promptEditorial
Inspect the Agent Skill "qdrant-scaling-qps" from https://github.com/github/awesome-copilot/blob/9933dcad5be5caeb288cebcd370eeeb2fc2f1685/skills/qdrant-scaling/scaling-qps/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
Performance Tuning for Higher RPS
Use fewer, larger segments (defaultsegmentnumber: 2) Maximizing throughput
Use fewer, larger segments (defaultsegmentnumber: 2) Maximizing throughputEnable quantization with alwaysram=true to reduce disk IO QuantizationUse batch search API to amortize overhead Batch search - 02
Minimize impact of Update Workloads
Configure update throughput control (v1.17+) to prevent unoptimized searches degrading reads Low latency search
Configure update throughput control (v1.17+) to prevent unoptimized searches degrading reads Low latency searchSet optimizercpubudget to limit indexing CPUs (e.g. 2 on an 8-CPU node reserves 6 for queries)Configure delayed read fan-out (v1.17+) for tail latency Delayed fan-outs - 03
Horizontal Scaling for Throughput
If a single node is saturated on CPU after applying the tuning above, scale horizontally with read replicas.
Shard replicas serve queries from replicated shards, distributing read load across nodesEach replica adds independent query capacity without re-shardingUse replicationfactor: 2+ and route reads to replicas Distributed deployment - 04
Disk I/O Bottlenecks
If it is not possible to keep all vectors in RAM, disk I/O can become the bottleneck for throughput. In this case:
Upgrade to provisioned IOPS or local NVMe first. See impact of disk performance to vector search in Disk performance articleUse iouring on Linux (kernel 5.11+) iouring articleIn case of quantized vectors, prefer global rescoring over per-segment rescoring to reduce disk reads. Example in the tutorial
Permission review
Static risk signals and limitations
Network access
The documentation includes network, browsing, or remote request actions.
Use batch search API to amortize overhead [Batch search](https://search.qdrant.tech/md/documentation/search/search/?s=batch-search-api)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-qps/SKILL.md
- Commit
- 9933dcad5be5caeb288cebcd370eeeb2fc2f1685
- License
- MIT
- Collected
- 2026-07-28
- Default branch
- main
View the original SKILL.md
Scaling for Query Throughput (QPS)
Throughput scaling means handling more parallel queries per second. This is different from latency - throughput and latency are opposite tuning directions and cannot be optimized simultaneously on the same node.
High throughput favors fewer, larger segments so each query touches less overhead.
Performance Tuning for Higher RPS
- Use fewer, larger segments (
default_segment_number: 2) Maximizing throughput - Enable quantization with
always_ram=trueto reduce disk IO Quantization - Use batch search API to amortize overhead Batch search
Minimize impact of Update Workloads
- Configure update throughput control (v1.17+) to prevent unoptimized searches degrading reads Low latency search
- Set
optimizer_cpu_budgetto limit indexing CPUs (e.g.2on an 8-CPU node reserves 6 for queries) - Configure delayed read fan-out (v1.17+) for tail latency Delayed fan-outs
Horizontal Scaling for Throughput
If a single node is saturated on CPU after applying the tuning above, scale horizontally with read replicas.
- Shard replicas serve queries from replicated shards, distributing read load across nodes
- Each replica adds independent query capacity without re-sharding
- Use
replication_factor: 2+and route reads to replicas Distributed deployment
See also Horizontal Scaling for general horizontal scaling guidance.
Disk I/O Bottlenecks
If it is not possible to keep all vectors in RAM, disk I/O can become the bottleneck for throughput. In this case:
- Upgrade to provisioned IOPS or local NVMe first. See impact of disk performance to vector search in Disk performance article
- Use
io_uringon Linux (kernel 5.11+) io_uring article - In case of quantized vectors, prefer global rescoring over per-segment rescoring to reduce disk reads. Example in the tutorial
- Configure higher number of search threads to parallelize disk reads. Default is
cpu_count - 1, which is optimal for RAM-based search but may be too low for disk-based search. See configuration reference - If still saturated, scale out horizontally (each node adds independent IOPS)
What NOT to Do
- Do not expect to optimize throughput and latency simultaneously on the same node
- Do not use many small segments for throughput workloads (increases per-query overhead)
- Do not scale horizontally when IOPS-bound without also upgrading disk tier
- Do not run at >90% RAM (OS cache eviction = severe performance degradation)