Best for
- Use when someone reports 'uploads are slow', 'indexing takes forever', 'optimizer is stuck', 'HNSW build time too long', or 'data uploaded but search is bad'.
github/awesome-copilot/skills/qdrant-performance-optimization/indexing-performance-optimization/SKILL.md
Diagnoses and fixes slow Qdrant indexing and data ingestion. Use when someone reports 'uploads are slow', 'indexing takes forever', 'optimizer is stuck', 'HNSW build time too long', or 'data uploaded but search is bad'. Also use when optimizer status shows errors, segments won't merge, or indexing threshold questions arise.
Decision brief
Qdrant does NOT build HNSW indexes immediately. Small segments use brute-force until they exceed indexingthresholdkb (default: 20 MB). Search during this window is slower by design, not a bug.
Compatibility matrix
| 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
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
npx skills add https://github.com/github/awesome-copilot --skill "skills/qdrant-performance-optimization/indexing-performance-optimization"Inspect the Agent Skill "qdrant-indexing-performance-optimization" from https://github.com/github/awesome-copilot/blob/9933dcad5be5caeb288cebcd370eeeb2fc2f1685/skills/qdrant-performance-optimization/indexing-performance-optimization/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
Use when: upload or upsert API calls are slow. Identify bottleneck: client-side (network, batching) vs server-side (CPU, disk I/O)
Use when: optimizer running for hours, not finishing.
Use when: HNSW index build dominates total indexing time.
If you have a multi-tenant use case where all data is split by some payload field (e.g. tenantid), you can avoid building a global HNSW index and instead rely on payloadm to build HNSW index only for subsets of data. Skipping global HNSW index can significantly reduce indexing t…
Qdrant builds extra HNSW links for all payload indexes to ensure that quality of filtered vector search does not degrade. Some payload indexes (e.g. text fields with long texts) can have a very high number of unique values per point, which can lead to long HNSW build time.
Permission review
The documentation includes network, browsing, or remote request actions.
Use batch upserts (64-256 points per request) [Points API](https://search.qdrant.tech/md/documentation/manage-data/points/?s=upload-points)Evidence record
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 74/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
Qdrant does NOT build HNSW indexes immediately. Small segments use brute-force until they exceed indexing_threshold_kb (default: 20 MB). Search during this window is slower by design, not a bug.
Use when: upload or upsert API calls are slow. Identify bottleneck: client-side (network, batching) vs server-side (CPU, disk I/O)
For client-side, optimize batching and parallelism:
For server-side, optimize Qdrant configuration and indexing strategy:
Suitable for initial bulk load of large datasets:
indexing_threshold_kb very high, restore after) Collection paramsm=0 to disable HNSW is legacy, use high indexing_threshold_kb insteadCareful, fast unindexed upload might temporarily use more RAM and degrade search performance until optimizer catches up.
See https://search.qdrant.tech/md/documentation/tutorials-develop/bulk-upload/
Use when: optimizer running for hours, not finishing.
optimizer_status shows an error, check logs for disk full or corrupted segmentsUse when: HNSW index build dominates total indexing time.
m (default 16, good for most cases, 32+ rarely needed) HNSW paramsef_construct (100-200 sufficient) HNSW configmax_indexing_threads proportional to CPU cores ConfigurationIf you have a multi-tenant use case where all data is split by some payload field (e.g. tenant_id), you can avoid building a global HNSW index and instead rely on payload_m to build HNSW index only for subsets of data.
Skipping global HNSW index can significantly reduce indexing time.
See Multi-tenant collections for details.
Qdrant builds extra HNSW links for all payload indexes to ensure that quality of filtered vector search does not degrade.
Some payload indexes (e.g. text fields with long texts) can have a very high number of unique values per point, which can lead to long HNSW build time.
You can disable building extra HNSW links for specific payload index and instead rely on slightly slower query-time strategies like ACORN.
Read more about disabling extra HNSW links in documentation
Read more about ACORN in documentation
m=0 for bulk uploads into an existing collection, it might drop the existing HNSW and cause long reindexing