Skip to main content

Buyer guide

Qdrant Production Playbook

A checklist for taking Qdrant to production: payload indexes before ingest, memory and disk headroom, supported storage, and staged upgrades.

Reading time
2 min read
Sources
11 cited

Model the payload and create indexes before ingesting, size memory and disk with headroom, choose where Qdrant runs, and stage upgrades with a recovery test. Each step cites Qdrant's documentation and public accounts from teams running it.

When you need this

  • A Qdrant prototype is moving to production traffic with metadata filters.
  • A self-hosted cluster on Kubernetes needs an upgrade or a recovery plan.
  • The team is choosing between self-hosting and a Qdrant Cloud tier.

Evaluation criteria

  1. Payload indexes before ingest

    Is every field you filter on indexed before data arrives?

    Look forCreate payload indexes for the fields you plan to filter on, since the filterable HNSW index only adds filter-aware edges when they exist first. A team with nested array filters saw 20 to 50 queries per second against about 1500 unfiltered (March 2026).

  2. Recall under filters

    Does filtered search find what exact search finds?

    Look forCompare filtered results against exact search on your own data. One founder found 34% of points in the top 100 with a tenant filter against 100% with exact search (August 2025).

  3. Memory and disk headroom

    What happens when a node runs short?

    Look forKeep quantized vectors and HNSW in RAM where you can, leave disk for deletes and optimizer runs, and set memory limits well above steady state so recovery does not loop. Turn on resource quotas from v1.19.0.

  4. Storage and placement

    Is the storage supported?

    Look forUse block-level storage with a POSIX-compatible file system. Qdrant does not work with NFS or S3, and a maintainer called Azure File Share unsupported with a risk of later data corruption.

  5. Upgrades and snapshots

    How will you upgrade and restore?

    Look forUpgrade through each minor release on staging first. Collection snapshots do not carry aliases, so restore aliases with a separate request.

Questions to ask vendors

  1. Which fields do our queries filter on, and are they indexed before ingest?
  2. How much free disk does each node keep for deletes and recovery?
  3. Which release are we on, and when did we last test an upgrade on staging?
  4. Do we need single sign-on, and is it in our Premium order?

Red flags

  • Filters on fields with no payload index.
  • Memory limits set at steady-state use.
  • Network file systems or object storage under a self-hosted node.
  • Upgrades applied straight to production.

Products in this piece

Sources

Official documentation
6
Public source
5
  1. Qdrant docs: InstallationOfficial documentationqdrant.tech
  2. Qdrant docs: Resource quotasOfficial documentationqdrant.tech
  3. Qdrant docs: FilteringOfficial documentationqdrant.tech
  4. Qdrant docs: IndexingOfficial documentationqdrant.tech
  5. Qdrant docs: Premium tierOfficial documentationqdrant.tech
  6. Qdrant docs: Cloud account setupOfficial documentationqdrant.tech
  7. qdrant/qdrant issue #8409: nested filter throughput (Mar 16, 2026)Public sourcegithub.com
  8. qdrant/qdrant issue #7147: filtered recall on a tenant index (Aug 26, 2025)Public sourcegithub.com
  9. Manfred Dreese: three years with Qdrant (Apr 23, 2026)Public sourcedreese.de
  10. qdrant/qdrant issue #7121: slow shard recovery after a restart (Aug 23, 2025)Public sourcegithub.com
  11. qdrant/qdrant issue #7813: disk use after deleting points (Dec 21, 2025)Public sourcegithub.com