What is stored on disk versus kept in memory by Qdrant, and why does that matter for container volumes?
Persistence and memory
Qdrant uses persistent storage for its database data under the configured storage directory, while indexes and working data also consume memory during operation. The exact memory footprint depends on the collection, index configuration, payload indexes, caching, and workload.
For containers, the important operational point is that the storage directory must live on durable storage if data must survive container replacement. A container's writable layer is not a reliable database persistence strategy.
Memory sizing also matters because vector indexes can consume substantial RAM. Persisting data to disk does not mean the database can operate with arbitrarily little memory; search performance and index behavior still depend on available resources.
A common mistake is thinking 'the database is on disk, therefore RAM does not matter.' Production sizing must account for both persistent storage and memory used by indexes and active workloads. Exact storage and memory behavior can vary by Qdrant version and configuration.
- 1
Mount durable storage at Qdrant's storage directory
- 2
Container filesystem layers should not be treated as durable database storage
- 3
Vector and payload indexes can require substantial memory
- 4
Size disk and RAM independently according to workload and configuration
Scenario Questions
0-2 years experience
- 1A Qdrant Docker container restarts and all collections disappear. What does this suggest about its storage configuration?
- 2Your disk has plenty of free space but the Qdrant process is out of memory. Why are disk capacity and RAM capacity separate concerns?
2-5 years experience
- 1A persistent volume is mounted, but Qdrant performance is poor after restarting because indexes need to be rebuilt or loaded. What resource characteristics would you investigate?
- 2Your container platform can replace containers at any time. What storage guarantee do you require before deploying Qdrant there?
5-8 years experience
- 1Your collection grows from 10 million to 200 million vectors and memory pressure becomes the primary incident driver. How would you approach resource sizing and index configuration?
- 2A storage migration moves Qdrant to slower disks and search latency increases. How would you determine whether disk I/O or memory pressure is responsible?
8+ years experience
- 1You need to design infrastructure for a very large Qdrant deployment. How would you model RAM, persistent storage, index overhead, replication, and growth headroom?
- 2Your cloud provider offers cheap high-capacity storage with poor IOPS and expensive fast storage. How would you decide which storage tier to use for Qdrant?
Follow-up Questions
- Why can a persistent Qdrant deployment still require substantial RAM?
- What would you verify about a persistent volume before using it for production Qdrant?