Attribution: Sourced from qdrant/skills by Qdrant.
Which Qdrant Deployment Do I Need?
Start with what you need: managed ops or full control? Network latency acceptable or not? Production or prototyping? The answer narrows to one of four options.
Getting Started or Prototyping
Use when: building a prototype, running tests, CI/CD pipelines, or learning Qdrant.
- Use local mode (Python only): zero-dependency, in-memory or disk-persisted, no server needed Local mode
- Local mode data format is NOT compatible with server. Do not use for production or benchmarking.
- For a real server locally, use Docker Quick start
Going to Production (Self-Hosted)
Use when: you need full control over infrastructure, data residency, or custom configuration.
- Docker is the default deployment. Full Qdrant Open Source feature set, minimal setup. Quick start
- You own operations: upgrades, backups, scaling, monitoring
- Must set up distributed mode manually for multi-node clusters Distributed deployment
- Consider Hybrid Cloud if you want Qdrant Cloud management on your infrastructure Hybrid Cloud
Going to Production (Zero-Ops)
Use when: you want managed infrastructure with zero-downtime updates, automatic backups, and resharding without operating clusters yourself.
- Qdrant Cloud handles upgrades, scaling, backups, and monitoring Qdrant Cloud
- Supports multi-version upgrades automatically
- Provides features not available in self-hosted:
/sys_metrics, managed resharding, pre-configured alerts
Need Lowest Possible Latency
Use when: network round-trip to a server is unacceptable. Edge devices, in-process search, or latency-critical applications.
- Qdrant EDGE: in-process bindings to Qdrant shard-level functions, no network overhead Qdrant EDGE
- Same data format as server. Can sync with server via shard snapshots.
- Single-node feature set only. No distributed mode.
What NOT to Do
- Use local mode for production or benchmarking (not optimized, incompatible data format)
- Self-host without monitoring and backup strategy (you will lose data or miss outages)
- Choose EDGE when you need distributed search (single-node only)
- Pick Hybrid Cloud unless you have data residency requirements (unnecessary Kubernetes complexity when Qdrant Cloud works)
1---2name: qdrant-deployment-options3description: Use when choosing how to run Qdrant: local mode, Docker, Qdrant Cloud, or self-hosted Kubernetes. Narrows the choice by managed ops versus full control, acceptable network latency, and prototyping versus production.4---56> **Attribution:** Sourced from [qdrant/skills](https://github.com/qdrant/skills) by [Qdrant](https://qdrant.tech).78# Which Qdrant Deployment Do I Need?910Start with what you need: managed ops or full control? Network latency acceptable or not? Production or prototyping? The answer narrows to one of four options.111213## Getting Started or Prototyping1415Use when: building a prototype, running tests, CI/CD pipelines, or learning Qdrant.1617- Use local mode (Python only): zero-dependency, in-memory or disk-persisted, no server needed [Local mode](https://search.qdrant.tech/md/documentation/quickstart/)18- Local mode data format is NOT compatible with server. Do not use for production or benchmarking.19- For a real server locally, use Docker [Quick start](https://search.qdrant.tech/md/documentation/quickstart/?s=download-and-run)202122## Going to Production (Self-Hosted)2324Use when: you need full control over infrastructure, data residency, or custom configuration.2526- Docker is the default deployment. Full Qdrant Open Source feature set, minimal setup. [Quick start](https://search.qdrant.tech/md/documentation/quickstart/?s=download-and-run)27- You own operations: upgrades, backups, scaling, monitoring28- Must set up distributed mode manually for multi-node clusters [Distributed deployment](https://search.qdrant.tech/md/documentation/operations/distributed_deployment/)29- Consider Hybrid Cloud if you want Qdrant Cloud management on your infrastructure [Hybrid Cloud](https://search.qdrant.tech/md/documentation/hybrid-cloud/)303132## Going to Production (Zero-Ops)3334Use when: you want managed infrastructure with zero-downtime updates, automatic backups, and resharding without operating clusters yourself.3536- Qdrant Cloud handles upgrades, scaling, backups, and monitoring [Qdrant Cloud](https://search.qdrant.tech/md/documentation/cloud-quickstart/)37- Supports multi-version upgrades automatically38- Provides features not available in self-hosted: `/sys_metrics`, managed resharding, pre-configured alerts394041## Need Lowest Possible Latency4243Use when: network round-trip to a server is unacceptable. Edge devices, in-process search, or latency-critical applications.4445- Qdrant EDGE: in-process bindings to Qdrant shard-level functions, no network overhead [Qdrant EDGE](https://search.qdrant.tech/md/documentation/edge/edge-quickstart/)46- Same data format as server. Can sync with server via shard snapshots.47- Single-node feature set only. No distributed mode.484950## What NOT to Do5152- Use local mode for production or benchmarking (not optimized, incompatible data format)53- Self-host without monitoring and backup strategy (you will lose data or miss outages)54- Choose EDGE when you need distributed search (single-node only)55- Pick Hybrid Cloud unless you have data residency requirements (unnecessary Kubernetes complexity when Qdrant Cloud works)