Qdrant storage for RAG: map data, memory tiers, and recovery copies

Inventory the Qdrant dataset

A RAG pipeline can retain source documents, generated embeddings, searchable payload, indexes, and one or more recovery copies. Those objects have different growth rates and owners. Count a collection from its actual schema and retained points, then list source and recovery artifacts separately. Chunk count is not automatically document count: record how the ingestion process turns source items into points and how updates or deletions affect retention.

Collection and vector fields

Make one row per collection and one sub-row per named vector. Record the Qdrant version and deployment type, collection name, shard and replication settings, retained point count, vector name, vector kind, dimensions or observed sparse nonzero count, datatype, and the source of each value. Dense vectors have a fixed dimension count; sparse vectors store nonzero values and indexes and need a different estimate. Do not assume one embedding per source document.

For each dense named vector, keep the original representation as its own candidate size. If vector quantization is selected, record the quantization method, bytes per component, whether original vectors remain, and whether originals are retained for rescoring. The quantized representation is an additional structure in Qdrant’s capacity guidance, alongside original vectors; do not subtract it from the original estimate. Search quality and recall can change, so validate against the selected embedding model and query workload before adopting it. Vector quantization changes stored search vectors. It is distinct from quantizing an LLM’s weights or its KV cache, which belong to a separate model-serving worksheet.

Record the source corpus too: original files, extracted text, chunking output, and any embedding-generation staging files that remain on disk. These are not Qdrant vector bytes. State whether they live on the same host or volume, whether they are retained after ingestion, and which owner can regenerate them. A corpus that can be regenerated is still a storage and transfer input while it is retained or recreated.

HNSW, payload, and indexes

Complete this structure ledger for every collection. Use observed measurements from a representative sample where available; mark estimates and unknowns explicitly. “Average payload size” should name the fields and encoding measured, not merely the source document size. Do not count an alternative tier twice.

For payload indexing, list only fields that the workload filters on and identify array indexes separately. Indexing every payload field can add cost without serving a query need. Include WAL, optimizer temporary work, operating-system cache, and other runtime use as separate planning rows rather than silently treating them as part of vector bytes. Monitor a representative load and search pattern before treating estimates as a procurement requirement.

Independent copies

Make a copy register with one row for each selected copy: live collection, replica, collection or shard snapshot, exported archive, independent backup, migration staging, and recovery destination. Record source and destination, consistency boundary, retained versions, location, unit, owner, and whether it overlaps another row. A replica is an availability copy within the deployment design; it is not automatically an independent backup. A snapshot is not a complete recovery plan by itself.

Do not add hypothetical copies “for safety” to the live estimate, but do not omit an actual retained copy because it has a different name. If a copy’s size or retention is unknown, preserve an UNKNOWN value and make it a gate for the billable total. Write down whether a target already contains data and whether migration temporarily holds both source and destination artifacts.

Interpret Qdrant memory tiers carefully

Qdrant’s captured memory-tier documentation describes per-structure placement, including pinned, cached, and cold behavior. In broad terms, pinned structures stay resident in RAM; cached structures use memory-mapped storage and may be warmed or cached; cold structures remain on disk until accessed, with active pages still able to occupy operating-system cache. Every structure remains persisted on disk. “Cold” therefore does not mean zero RAM, and “on disk” does not mean the host needs no memory for Qdrant, the operating system, indexes, writes, or co-resident services.

The captured capacity guide reports defaults for individual structures, but those defaults and configuration names must be checked against the exact Qdrant release and selected deployment. Record the version, per-structure tier, and evidence for the configured value. Low Memory startup mode is a separate startup choice described for its documented version context; it is not a substitute for a structure-by-structure plan or a safe default for every collection.

Make two totals rather than one: all persisted structure estimates for disk, then only the selected pinned/cached or otherwise resident portions for Qdrant RAM planning. Add the application process, OS needs, active working set, ingestion/optimization peaks, and other resident services as separate fields. A cold-vector design can reduce planned vector residency while increasing dependence on disk access patterns and storage behavior. This page does not predict latency or declare a plan suitable without measurements.

Estimate disk by scenario

The following worksheet transcribes the captured Qdrant Capacity Planning approximations (AI21, captured 2026-11-06). Recheck the current document and the selected release before use; datatypes, tier defaults, and quantization details are version/configuration scoped. Use bytes throughout the arithmetic, convert only for reporting, and calculate each collection and each named vector separately. These are Qdrant-specific planning estimates, not universal database or RAG formulas, legal requirements, or total-server sizing.

Steady-state planning

For each collection, set number_of_points to retained points, replication_factor to the selected factor, and base = number_of_points × replication_factor. Populate only structures present in that collection. The table names the inputs and captured approximations; the row owner should retain the source version, sample, tier, and any measured replacement values alongside the result.

Sum dense rows per named vector; sparse rows per sparse vector; and selected payload/index rows. Treat the formulas as approximate components, not exact disk allocation or observed RAM. In particular, payload distributions, sparse nnz, optimizer behavior, and actual file allocation can differ from a single average. The disk total includes all persisted structures, independent of tier. The Qdrant memory total includes the structures assigned to relevant pinned/cached tiers under the selected configuration, not every byte of disk data. Keep OS cache and Qdrant/runtime overhead visible.

The same captured guide recommends approximately 20% headroom on its calculated RAM and disk totals to account for operating-system page cache, runtime overhead, temporary optimizer work, WAL, snapshots, and temporary segments. Show this as a separate line: steady estimate × 1.20. It is a documented planning allowance, not a universal provider rule, guaranteed safety margin, or substitute for observed growth and actual recovery requirements. Do not confuse it with the separate migration/restore scenario below.

For the reader’s worksheet, copy and fill this template; blank values remain unresolved rather than becoming zero:

Collection: ______  Qdrant version: ______  as-of: ______  owner: ______
points: ______ points   replication_factor: ______   base: ______ points
Named dense vector / dims / bytes_per_dim / tier / bytes: ______
Quantized copy? method / quant_bytes / originals retained / bytes: ______
HNSW per dense name / m / tier / bytes: ______
Sparse name / average nnz / bytes_per_dim / vector bytes / index bytes: ______
Payload avg bytes per point / fields / tier / disk bytes / cached RAM: ______
Payload indexes / indexed bytes / per-element index count / bytes: ______
ID tracker tier / estimated bytes: ______
Other observed Qdrant, WAL, cache or optimizer use / source: ______
Persisted structure subtotal (bytes): ______   selected structure RAM (bytes): ______
Documented ~20% planning line, applied separately: ______
Measured sample, measurement window and difference from estimate: ______
UNKNOWN inputs / stop condition: ______

Use the selected datatype’s byte width and versioned configuration. Do not copy a number from an example collection and present it as a host requirement. If input values are estimated from a sample, record sample size, workload, method, and owner so a later reader can decide whether it represents current production data.

Migration and restore peak

Keep a scenario row for steady state and another for migration or snapshot restore. The captured AI21 capacity guidance says its migration-tool or snapshot-restore target may need roughly twice the source collection’s current disk use; its migration-tool context also calls for roughly twice current RAM use. Preserve that specific source context. This is not a general 2× disk or RAM law, not the same as the ordinary ~20% headroom line, and not a blanket promise for every restore path or provider.

Record source measured disk/RAM and measurement time, target Qdrant version, compatibility path, destination free space, whether source and destination coexist, archive/download/unpack staging, other collections on the target, and whether multiple shards or nodes need separate artifacts. Qdrant snapshot documentation describes collection snapshots as tied to a specific collection, node, and time; in a distributed setup, coverage may require snapshots for each node. Confirm the current procedure and scope for the selected deployment before relying on an archive as complete recovery.

Do not stack mutually exclusive alternatives into one peak. Name the actual operation: in-place recovery, new target migration, export and import, or provider-level copy. For each, state the bytes present at the busiest point, the free-space threshold, target RAM assumption, time window, and person authorized to stop the attempt. If compatibility or overlap is unclear, leave the required peak UNKNOWN and do not approve the destination capacity.

Snapshot and remote-copy behavior

For every snapshot or export, record whether it covers a collection, shard, node, or broader deployment; Qdrant version and compatibility requirements; creation time; format; storage location; retention; and whether the copy can be reached from the recovery environment. Captured Qdrant snapshot guidance says a snapshot can be restored to a cluster on the same minor version or the next minor version. This is a minor-version boundary in that captured guidance, not arbitrary major-version compatibility and not a guarantee that a backup or restore will succeed. Recheck compatibility for the exact selected source and target releases and procedure; if that evidence or the artifact’s scope is unclear, keep compatibility UNKNOWN and stop before relying on the restore. A remote URL restore depends on the destination being able to reach that URL. Distribution priority and restore scheduling can affect when replicas or shards are available; verify the selected version’s documented behavior rather than assuming a snapshot is instantly restored everywhere.

Separate local snapshot files from an independent copy. If the source host or its disk is lost, a file stored only on that same disk may be lost with it. Record copy location, encryption/access owner, transfer quantity, retention rule, and who is permitted to remove an expired artifact. Qdrant Cloud and self-hosted storage paths can differ; check the matching procedure, supported format, and billable storage/transfer scope.

Issue #10207 (AI45) is an open feature request describing a reporter’s concern about an uploaded snapshot remaining alongside restored collection data. It is not proof of current universal restore behavior or a supported automatic cleanup option. Do not rely on a delete_after_restore flag or other unverified cleanup behavior. For the selected release, document the actual retention and manual cleanup procedure separately, with an owner and post-recovery verification step.

Turn quantities into billable inputs

This page produces Qdrant-related quantities, not the full VPS bill. Transfer each selected quantity once into the Local AI storage and egress cost worksheet, where billing period, provider units, included amounts, rates, and totals belong. Do not infer a zero charge from an unknown rate or an advertised included quantity.

Keep disk, system RAM, and cache in separate columns. RAM is a host-capacity input, not automatically a storage billable quantity; cache may be filesystem or process behavior, not a separately charged disk copy. Provider volume size, snapshot charges, backup retention, and transfer pricing must come from the exact product and current terms. Pass measured and estimated values with their units to Article 2; that page alone rolls up the total.

If Qdrant shares a host with an inference runtime or workflow service, capture placement and contention as separate architecture inputs. The same-box versus split service decision covers placement relative to n8n. For model weights, runtime allocations, VRAM, and LLM KV cache, use the distinct model and memory worksheet; those values do not belong in Qdrant’s vector formulas.

Recovery acceptance and pressure prompts

Before relying on a recovery plan, fill an acceptance record for a specific collection and destination. Define the recovery point (which updates and time are covered), target Qdrant version, source and independent copy, restore location, compatibility evidence, available disk/RAM threshold, expected shard/node coverage, integrity or record-count checks, restore owner, and stop conditions. Record how a recovered collection will be checked against the expected collection identity and representative records before callers are redirected. These are proposed reader observations, not tests performed for this article.

1. Scope: list collections, nodes/shards, point in time, source schema and target version. Confirm the chosen snapshot/export covers that scope.
2. Capacity: compare source measurements with target free disk and planned RAM; include archive, extraction, temporary and concurrent-copy needs. Stop if the peak is unknown or insufficient.
3. Compatibility: verify the selected Qdrant release’s snapshot/restore version constraints and supported procedure before copying valuable state.
4. Independence: identify a copy outside the failure boundary, its retention, access control, reachability, and the owner who can retrieve it.
5. Acceptance: specify version, collection status, expected counts or integrity evidence, application read path, and who approves return to service.
6. Cleanup gate: after accepted recovery, inspect retained source/archive/staging copies and apply only the selected documented procedure under the named owner. Do not assume cleanup ran automatically.

Set a free-space alert threshold above the planned operation peak, with an explicit margin selected for the actual write and restore behavior. Capture filesystem capacity and Qdrant disk metrics using the selected version’s documented monitoring method; the captured docs describe a node /metrics endpoint, but the endpoint’s exposure and collection method must be secured and verified for the chosen deployment. Never expose metrics or the Qdrant API publicly as a capacity check. For endpoint reachability and caller paths, see the private network and bind decision.

Do not treat a capacity worksheet or issue report as a restore rehearsal. A future controlled recovery exercise needs an isolated destination, authorized data, a recorded source and target version, a rollback point, and a stop condition. This article does not claim a collection was restored, a disk threshold measured, or an endpoint tested.

Evidence and update gate

Source capture(s) checked 2026-11-06. The formulas and tier descriptions below are bounded by the captured Qdrant documentation and the selected version; confirm current documentation, configuration, and provider storage units before procurement or recovery. Dataset dimensions, sparse density, payload distribution, index selection, replica layout, filesystem behavior, restore compatibility, and billing quantities remain workload- and version-specific.

• Qdrant Capacity Planning — captured structure formulas, selected tiers, approximately 20% planning headroom, and the specific migration/restore context.
• Qdrant Storage — persistent data and storage behavior.
• Qdrant Memory Tiers — per-structure placement; verify exact release behavior.
• Qdrant Snapshots — snapshot coverage and recovery considerations; verify version compatibility.
• Qdrant Vectors — dense and sparse vector distinction.
• Qdrant Security — captured self-hosted network and authentication guidance; confirm current configuration.
• Qdrant Monitoring — captured node metrics scope.
• Qdrant issue #11315 — one v1.20.0 disk-full report, not a prevalence or support claim.
• Qdrant issue #10207 — open snapshot cleanup feature request, not an implemented feature contract.

Return to the Local AI selection hub when choosing the overall workload. This article owns Qdrant structure and recovery quantities; Article 2 owns aggregate cost; Article 4 owns LLM artifact and memory; Article 8 owns endpoint reachability; Article 10 owns resident-service placement relative to n8n. Method and source-capture context is available on Methodology.

Drafting checks: source captures above were read; this article was reviewed for its required section order, anchors, internal destinations, and qualified recovery examples. No deployment, restore, performance, or endpoint test is claimed.