Source profileQuality 74/100

github/awesome-copilot/skills/qdrant-performance-optimization/indexing-performance-optimization/SKILL.md

qdrant-indexing-performance-optimization

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.

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

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.

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'.

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

PlatformStatusEvidenceWhat to check
CodexNot declaredNo explicit evidencePortability before use
Claude CodeNot declaredNo explicit evidencePortability before use
CursorNot declaredNo explicit evidencePortability before use
Gemini CLINot declaredNo explicit evidencePortability 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-performance-optimization/indexing-performance-optimization"
Safe inspection promptEditorial

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

What the source asks the agent to do

  1. 01

    Uploads/Ingestion Too Slow

    Use when: upload or upsert API calls are slow. Identify bottleneck: client-side (network, batching) vs server-side (CPU, disk I/O)

    Use batch upserts (64-256 points per request) Points APIUse 2-4 parallel upload streamsCreate more shards (3-12), each shard has an independent update worker Sharding
  2. 02

    Optimizer Stuck or Taking Too Long

    Use when: optimizer running for hours, not finishing.

    Check actual progress via optimizations endpoint (v1.17+) Optimization monitoringLarge merges and HNSW rebuilds legitimately take hours on big datasetsCheck CPU and disk I/O (HNSW is CPU-bound, merging is I/O-bound, HDD is not viable)
  3. 03

    HNSW Build Time Too High

    Use when: HNSW index build dominates total indexing time.

    Reduce m (default 16, good for most cases, 32+ rarely needed) HNSW paramsReduce efconstruct (100-200 sufficient) HNSW configKeep maxindexingthreads proportional to CPU cores Configuration
  4. 04

    HNSW index for multi-tenant collections

    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…

    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. Sk…See Multi-tenant collections for details.
  5. 05

    Additional Payload Indexes Are Too Slow

    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.

    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 val…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

Permission review

Static risk signals and limitations

Network access

medium · line 15

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

Why each signal appears

EvidenceSourceComputedTestedEditorial
SignalValueEvidence typeMeaning
Quality score74/100ComputedDocumentation, specificity, maintenance, and trust rules
Repository stars37,126SourceRepository attention, not individual Skill quality
Compatibility0 platformsSourceDeclared in the catalog source record
Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

Pinned source

Provenance and original SKILL.md

Repository
github/awesome-copilot
Skill path
skills/qdrant-performance-optimization/indexing-performance-optimization/SKILL.md
Commit
9933dcad5be5caeb288cebcd370eeeb2fc2f1685
License
MIT
Collected
2026-07-28
Default branch
main
View the original SKILL.md

What to Do When Qdrant Indexing Is Too Slow

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.

Uploads/Ingestion Too Slow

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:

  • Use batch upserts (64-256 points per request) Points API
  • Use 2-4 parallel upload streams

For server-side, optimize Qdrant configuration and indexing strategy:

  • Create more shards (3-12), each shard has an independent update worker Sharding
  • Create payload indexes before HNSW builds (needed for filterable vector index) Payload index

Suitable for initial bulk load of large datasets:

  • Disable HNSW during bulk load (set indexing_threshold_kb very high, restore after) Collection params
  • Setting m=0 to disable HNSW is legacy, use high indexing_threshold_kb instead

Careful, 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/

Optimizer Stuck or Taking Too Long

Use when: optimizer running for hours, not finishing.

  • Check actual progress via optimizations endpoint (v1.17+) Optimization monitoring
  • Large merges and HNSW rebuilds legitimately take hours on big datasets
  • Check CPU and disk I/O (HNSW is CPU-bound, merging is I/O-bound, HDD is not viable)
  • If optimizer_status shows an error, check logs for disk full or corrupted segments

HNSW Build Time Too High

Use when: HNSW index build dominates total indexing time.

HNSW index for multi-tenant collections

If 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.

Additional Payload Indexes Are Too Slow

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

What NOT to Do

  • Do not create payload indexes AFTER HNSW is built (breaks filterable vector index)
  • Do not use m=0 for bulk uploads into an existing collection, it might drop the existing HNSW and cause long reindexing
  • Do not upload one point at a time (per-request overhead dominates)