Qdrant scaling
Classify the scaling pressure first, then choose the Qdrant scaling strategy that matches the bottleneck instead of adding nodes blindly.
When to invoke
- "How many Qdrant nodes do I need?"
- "Our Qdrant data does not fit on one node."
- "Qdrant is slow; should we scale vertically or horizontally?"
- "How should we shard Qdrant for too many tenants?"
- "We need more QPS or lower query latency."
Scaling goal classifier
| Goal |
Primary symptom |
Pulls toward |
Tradeoff to watch |
Deep reference |
| Data volume |
Dataset exceeds memory, disk, or operational capacity of one node. |
Vertical scaling, horizontal sharding, tenant sharding, or sliding time windows. |
More shards increase coordination and operational complexity. |
scaling-data-volume/SKILL.md |
| Query throughput (QPS) |
Single node cannot handle enough parallel queries. |
Replicas, more nodes, load distribution, and query fan-out control. |
Throughput tuning can increase per-query latency. |
scaling-qps/SKILL.md |
| Query latency |
One query is too slow even when QPS is acceptable. |
Index tuning, payload filtering strategy, shard layout, hardware, and smaller search scope. |
Latency and throughput are correlated sometimes, but not always. |
minimize-latency/SKILL.md |
| Query volume |
Each query returns too many results or too much payload. |
Pagination, limits, payload projection, filtering, and result-size control. |
Large result sets increase latency and client/network cost. |
scaling-query-volume/SKILL.md |
Scaling for throughput and scaling for latency often push in opposite directions. Decide which one is the user's actual SLO before recommending topology changes.
Data-volume options
| Option |
Use when |
Avoid when |
| Vertical scaling |
One larger node can hold the working set with safe headroom. |
Hardware limits, downtime risk, or cost make a single large node fragile. |
| Horizontal scaling |
Collections exceed one node or need distributed capacity. |
Query fan-out would dominate latency. |
| Tenant scaling |
Many tenants have uneven size or noisy-neighbor risk. |
Tenant isolation is not required and operational simplicity matters more. |
| Sliding time window |
Recent vectors are queried often and old data can age out or move. |
Queries routinely span the full historical corpus. |
For detailed data-volume patterns, read scaling-data-volume/SKILL.md and its nested horizontal-scaling/SKILL.md, tenant-scaling/SKILL.md, vertical-scaling/SKILL.md, and sliding-time-window/SKILL.md resources when needed.
Measurement checklist
Collect these facts before prescribing node count or sharding:
- Collection count, vector count, vector dimension, payload size, index type, replication factor, and shard count.
- Current CPU, RAM, disk, IOPS, network, and p95/p99 latency under representative load.
- QPS target, latency SLO, result limit, payload returned per query, and filter selectivity.
- Tenant count, largest tenant size, hot-tenant skew, and isolation requirements.
- Whether the problem is capacity, ingestion, search throughput, single-query latency, or oversized responses.
Gotchas
- Do not treat all slowness as missing nodes: the slowest component in the query execution path determines latency.
- Do not optimize throughput and latency with the same knob by default: more parallelism can raise tail latency.
- Do not ignore query volume: returning too many results can look like search slowness even when vector search is fast.
- Do not shard without an access pattern: random sharding may increase fan-out and make filtered queries slower.
Progressive disclosure and bundled resources
scaling-data-volume/SKILL.md: data-size-driven scaling overview.scaling-data-volume/horizontal-scaling/SKILL.md: horizontal data scaling.scaling-data-volume/tenant-scaling/SKILL.md: tenant-oriented scaling.scaling-data-volume/vertical-scaling/SKILL.md: larger-node scaling.scaling-data-volume/sliding-time-window/SKILL.md: time-windowed collections.scaling-qps/SKILL.md: query throughput scaling.minimize-latency/SKILL.md: single-query latency reduction.scaling-query-volume/SKILL.md: large result-set control.
Output template
## Qdrant scaling recommendation
**Status:** recommendation | needs measurements | blocked
**Primary scaling goal:** data volume | query throughput | query latency | query volume
| Evidence | Interpretation | Recommendation |
| --- | --- | --- |
| `<metric or symptom>` | `<bottleneck>` | `<scaling action>` |
### Next checks
- `<measurement needed before changing topology>`
- `<reference file read, if any>`
Quality gate
1---2name: qdrant-scaling-23description: Guide Qdrant scaling decisions for data volume, query throughput, query latency, query volume, tenant growth, sharding, and capacity planning. Use when someone asks how many nodes are needed, whether to scale vertically or horizontally, why a cluster is slow, how to shard, or how to add capacity.4---56# Qdrant scaling78Classify the scaling pressure first, then choose the Qdrant scaling strategy that matches the bottleneck instead of adding nodes blindly.910## When to invoke1112- "How many Qdrant nodes do I need?"13- "Our Qdrant data does not fit on one node."14- "Qdrant is slow; should we scale vertically or horizontally?"15- "How should we shard Qdrant for too many tenants?"16- "We need more QPS or lower query latency."1718## Scaling goal classifier1920| Goal | Primary symptom | Pulls toward | Tradeoff to watch | Deep reference |21| --- | --- | --- | --- | --- |22| Data volume | Dataset exceeds memory, disk, or operational capacity of one node. | Vertical scaling, horizontal sharding, tenant sharding, or sliding time windows. | More shards increase coordination and operational complexity. | `scaling-data-volume/SKILL.md` |23| Query throughput (QPS) | Single node cannot handle enough parallel queries. | Replicas, more nodes, load distribution, and query fan-out control. | Throughput tuning can increase per-query latency. | `scaling-qps/SKILL.md` |24| Query latency | One query is too slow even when QPS is acceptable. | Index tuning, payload filtering strategy, shard layout, hardware, and smaller search scope. | Latency and throughput are correlated sometimes, but not always. | `minimize-latency/SKILL.md` |25| Query volume | Each query returns too many results or too much payload. | Pagination, limits, payload projection, filtering, and result-size control. | Large result sets increase latency and client/network cost. | `scaling-query-volume/SKILL.md` |2627Scaling for throughput and scaling for latency often push in opposite directions. Decide which one is the user's actual SLO before recommending topology changes.2829## Data-volume options3031| Option | Use when | Avoid when |32| --- | --- | --- |33| Vertical scaling | One larger node can hold the working set with safe headroom. | Hardware limits, downtime risk, or cost make a single large node fragile. |34| Horizontal scaling | Collections exceed one node or need distributed capacity. | Query fan-out would dominate latency. |35| Tenant scaling | Many tenants have uneven size or noisy-neighbor risk. | Tenant isolation is not required and operational simplicity matters more. |36| Sliding time window | Recent vectors are queried often and old data can age out or move. | Queries routinely span the full historical corpus. |3738For detailed data-volume patterns, read `scaling-data-volume/SKILL.md` and its nested `horizontal-scaling/SKILL.md`, `tenant-scaling/SKILL.md`, `vertical-scaling/SKILL.md`, and `sliding-time-window/SKILL.md` resources when needed.3940## Measurement checklist4142Collect these facts before prescribing node count or sharding:4344- Collection count, vector count, vector dimension, payload size, index type, replication factor, and shard count.45- Current CPU, RAM, disk, IOPS, network, and p95/p99 latency under representative load.46- QPS target, latency SLO, result limit, payload returned per query, and filter selectivity.47- Tenant count, largest tenant size, hot-tenant skew, and isolation requirements.48- Whether the problem is capacity, ingestion, search throughput, single-query latency, or oversized responses.4950## Gotchas5152- **Do not treat all slowness as missing nodes**: the slowest component in the query execution path determines latency.53- **Do not optimize throughput and latency with the same knob by default**: more parallelism can raise tail latency.54- **Do not ignore query volume**: returning too many results can look like search slowness even when vector search is fast.55- **Do not shard without an access pattern**: random sharding may increase fan-out and make filtered queries slower.5657## Progressive disclosure and bundled resources5859- `scaling-data-volume/SKILL.md`: data-size-driven scaling overview.60- `scaling-data-volume/horizontal-scaling/SKILL.md`: horizontal data scaling.61- `scaling-data-volume/tenant-scaling/SKILL.md`: tenant-oriented scaling.62- `scaling-data-volume/vertical-scaling/SKILL.md`: larger-node scaling.63- `scaling-data-volume/sliding-time-window/SKILL.md`: time-windowed collections.64- `scaling-qps/SKILL.md`: query throughput scaling.65- `minimize-latency/SKILL.md`: single-query latency reduction.66- `scaling-query-volume/SKILL.md`: large result-set control.6768## Output template6970```markdown71## Qdrant scaling recommendation7273**Status:** recommendation | needs measurements | blocked74**Primary scaling goal:** data volume | query throughput | query latency | query volume7576| Evidence | Interpretation | Recommendation |77| --- | --- | --- |78| `<metric or symptom>` | `<bottleneck>` | `<scaling action>` |7980### Next checks81- `<measurement needed before changing topology>`82- `<reference file read, if any>`83```8485## Quality gate8687- [ ] The recommendation names exactly one primary scaling goal and any secondary goals.88- [ ] Throughput, latency, data volume, and query volume were considered separately.89- [ ] Node-count guidance is backed by capacity or SLO measurements, or the output requests the missing measurements.90- [ ] Sharding advice explains the access pattern and fan-out tradeoff.91- [ ] The relevant bundled deep reference was named when the request required detailed topology guidance.
paulasilvatech