qdrant-scaling by github

Decision brief

What it does—and where it fits

First determine what you're scaling for:

Best for

Use when someone asks 'how many nodes do I need', 'data doesn't fit on one node', 'need more throughput', 'cluster is slow', 'too many tenants', 'vertical or horizontal', 'how to shard', or 'need to add capacity'.

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

Open the compatibility checker

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"

Safe inspection promptEditorial

Inspect the Agent Skill "qdrant-scaling" from https://github.com/github/awesome-copilot/blob/9933dcad5be5caeb288cebcd370eeeb2fc2f1685/skills/qdrant-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
Scaling Data Volume
This becomes relevant when volume of the dataset exceeds the capacity of a single node. Read more about scaling for data volume in Scaling Data Volume
This becomes relevant when volume of the dataset exceeds the capacity of a single node. Read more about scaling for data volume in Scaling Data Volume
02
Scaling for Query Throughput
If your system needs to handle more parallel queries than a single node can handle, then you need to scale for query throughput.
If your system needs to handle more parallel queries than a single node can handle, then you need to scale for query throughput.Read more about scaling for query throughput in Scaling for Query Throughput
03
Scaling for Query Latency
Latency of a single query is determined by the slowest component in the query execution path. It is in sometimes correlated with throughput, but not always. It might require different strategies for scaling.
Latency of a single query is determined by the slowest component in the query execution path. It is in sometimes correlated with throughput, but not always. It might require different strategies for scaling.Read more about scaling for query latency in Scaling for Query Latency
04
Scaling for Query Volume
By query volume we understand the amount of results that a single query returns. If the query volume is too high, it can cause performance issues and increase latency.
By query volume we understand the amount of results that a single query returns. If the query volume is too high, it can cause performance issues and increase latency.Tuning for query volume is opposite might require special strategies.Read more about scaling for query volume in Scaling for Query Volume

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	64/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/SKILL.md
Commit: 9933dcad5be5caeb288cebcd370eeeb2fc2f1685
License: MIT
Collected: 2026-07-28
Default branch: main

View the original SKILL.md

Qdrant Scaling

First determine what you're scaling for:

data volume
query throughput (QPS)
query latency
query volume

After determining the scaling goal, we can choose scaling strategy based on tradeoffs and assumptions. Each pulls toward different strategies. Scaling for throughput and latency are opposite tuning directions.

Scaling Data Volume

This becomes relevant when volume of the dataset exceeds the capacity of a single node. Read more about scaling for data volume in Scaling Data Volume

Scaling for Query Throughput

If your system needs to handle more parallel queries than a single node can handle, then you need to scale for query throughput.

Read more about scaling for query throughput in Scaling for Query Throughput

Scaling for Query Latency

Latency of a single query is determined by the slowest component in the query execution path. It is in sometimes correlated with throughput, but not always. It might require different strategies for scaling.

Read more about scaling for query latency in Scaling for Query Latency

Scaling for Query Volume

By query volume we understand the amount of results that a single query returns. If the query volume is too high, it can cause performance issues and increase latency.

Tuning for query volume is opposite might require special strategies.

Read more about scaling for query volume in Scaling for Query Volume