Published

Qdrant

Qdrant is an open-source vector database written in Rust: it stores embeddings with JSON payloads and serves similarity search over a REST and gRPC API, with a built-in Web UI. It fits teams building RAG or semantic search who want the vector store on their own server; its memory needs grow with the number and size of vectors.

Resources by load level

What the app itself needs at each level, next to what we recommend for a server that runs only this app.

Level	What it means	App requirements	Recommended
LightEstimate	Up to 100,000 vectors of 768 dimensions (float32) with ~1 KiB payload each, no quantization: a prototype or one small RAG knowledge base.	0.5 vCPU · 0.5 GiB RAM · 0.8 GiB disk	0.72 vCPU · 2.1 GiB RAM · 10.235 GiB disk
MediumEstimate	Up to 1 million vectors of 768 dimensions (float32) with ~1 KiB payload each, no quantization: several knowledge bases or a production semantic search.	2 vCPU · 3.75 GiB RAM · 5.6 GiB disk	2.52 vCPU · 6 GiB RAM · 15.755 GiB disk
HeavyEstimate	Up to 5 million vectors of 768 dimensions (float32) with ~1 KiB payload each, no quantization, on one node with replication factor 1.	4 vCPU · 18.5 GiB RAM · 27.1 GiB disk	4.92 vCPU · 23.7 GiB RAM · 40.48 GiB disk

Recommended = app requirements + system baseline + safety headroom, under sizing policy 2026.10.0. Options stay at their defaults. “Estimate” means the sources give no number for that case, so it is worked out from them by the method stated under Components. How the numbers are built

Size it in the Stack Sizer

Ready-to-run files

Support level Supported

Compose template from the official sources; not yet verified by a run.

Create docker-compose

Components

What each component needs at each load level, before baseline and headroom.

vCPU / GiB RAM / GiB disk
Component	Light	Medium	Heavy	Sources
Qdrant (database)	0.5 / 0.5 / 0.8	2 / 3.75 / 5.6	4 / 18.5 / 27.1	[4][10][11][12]

How the estimates are worked out

Qdrant · Light: Qdrant capacity planning, single node: dense = N × 768 × 4 B; HNSW = N × 16 × 2 × 4 B × 1.2; ID tracker = N × 52 B; payload (cold, 1 KiB) = N × 1,024 B × 1.5. RAM = (dense + HNSW + ID) × 1.2, disk = (all four) × 1.2 (the guide's 20% headroom); + image 0.189 GiB unpacked. N = 100,000: RAM (0.286 + 0.014 + 0.005) × 1.2 = 0.366 → 0.5 GiB; disk (0.448) × 1.2 = 0.538 + 0.189 = 0.727 → 0.8 GiB. vCPU: 0.5, the smallest Qdrant Cloud node.
Qdrant · Medium: Qdrant capacity planning, single node: dense = N × 768 × 4 B; HNSW = N × 16 × 2 × 4 B × 1.2; ID tracker = N × 52 B; payload (cold, 1 KiB) = N × 1,024 B × 1.5. RAM = (dense + HNSW + ID) × 1.2, disk = (all four) × 1.2 (the guide's 20% headroom); + image 0.189 GiB unpacked. N = 1M: RAM (2.861 + 0.143 + 0.048) × 1.2 = 3.663 → 3.75 GiB; disk (4.483) × 1.2 = 5.380 + 0.189 = 5.569 → 5.6 GiB. vCPU: the free-tier ratio of 0.5 vCPU per GB of RAM × ~4 GB = 2.
Qdrant · Heavy: Qdrant capacity planning, single node: dense = N × 768 × 4 B; HNSW = N × 16 × 2 × 4 B × 1.2; ID tracker = N × 52 B; payload (cold, 1 KiB) = N × 1,024 B × 1.5. RAM = (dense + HNSW + ID) × 1.2, disk = (all four) × 1.2 (the guide's 20% headroom); + image 0.189 GiB unpacked. N = 5M: RAM (14.305 + 0.715 + 0.242) × 1.2 = 18.315 → 18.5 GiB; disk (22.415) × 1.2 = 26.898 + 0.189 = 27.087 → 27.1 GiB. vCPU: 4, an allowance (no upstream figure): search and optimizer threads both auto-scale to the cores.

Ports

Public ports are meant to be reached from outside the stack, usually through a reverse proxy; internal ones stay on the stack's own network.

Component	Port	Exposure	Purpose	Sources
Qdrant	6333/tcp	Public, through a proxy	REST API, Web UI (/dashboard) and health/metrics; only with an API key and HTTPS	[1][4][6][14]
Qdrant	6334/tcp	Internal only	gRPC API for clients on the internal Docker network	[1][2][4]

Every port in the catalog, with conflicts between apps

User and permissions (UID/GID)

The user each container's process runs as, and the paths it writes to. A bind mount for one of these paths must be writable by that UID:GID.

Component	UID:GID	User	Starts as root	Writes to	Sources
Qdrant	1000:1000	`qdrant`	No	`/qdrant/storage/qdrant/snapshots`	[2][3][6][10][19]

Qdrant: The -unprivileged tags are built with USER_ID=1000: the Dockerfile creates user qdrant (1000:1000), creates /qdrant/storage and /qdrant/snapshots owned by it, and sets USER 1000:1000; entrypoint.sh never switches user. Docker copies that ownership into empty named volumes. The default tags run as root (USER_ID=0).

Storage growth

How much each component's data grows per month at each load level, on top of the disk in the profile. A value marked Assumption is ANAROQ's stated assumption, not a figure from the sources; the notes say what it rests on.

GiB per month
Component	Light	Medium	Heavy	Sources
QdrantAssumption	0.045	0.448	2.242	[9][11]

What the growth figures rest on

Qdrant: Growth depends only on how many points are added. ANAROQ assumes the collection reaches this preset's size (0.538 GiB on disk) in 12 months (0.538 / 12). Snapshots in /qdrant/snapshots are kept until deleted and are not counted.
Qdrant: Growth depends only on how many points are added. ANAROQ assumes the collection reaches this preset's size (5.380 GiB on disk) in 12 months (5.380 / 12). Snapshots in /qdrant/snapshots are kept until deleted and are not counted.
Qdrant: Growth depends only on how many points are added. ANAROQ assumes the collection reaches this preset's size (26.898 GiB on disk) in 12 months (26.898 / 12). Snapshots in /qdrant/snapshots are kept until deleted and are not counted.

Upgrade and rollback

How to move to a new version safely, and how to go back if it fails.

Back up first

Create a full storage snapshot (POST /snapshots) and copy it off the server, or copy the stopped /qdrant/storage volume. [9][13]DerivedThe upgrade guide names no backup step; the snapshot API and its restore rules come from the snapshots guide, and copying the stopped volume is inferred.

Upgrade steps

Read the release post of every minor version you cross, and update client SDKs first: they are tested against the latest 3 minor versions. [13][15]
Do not skip minor versions, even on a single node: go through the latest patch of each one (for example 1.17.x → 1.18.x → 1.19.2) so every data migration runs. [13][16]
Change the pinned image tag in the Compose file and run docker compose pull and docker compose up -d. A single node has a short downtime while it restarts. [13]

Roll back

Start the previous tag on a restored copy of the volume, or restore the snapshot (./qdrant --storage-snapshot) into the previous version. Snapshots restore only into the same or the next minor version, so a snapshot taken after upgrading cannot go back. [9]DerivedUpstream documents no downgrade; running the older tag on data saved before the upgrade is inferred from the snapshot version rule.

Known breaking changes

In 1.19.0: The legacy /search, /recommend and /discover endpoints were removed: move clients to the /query API first. The per-component on_disk, always_ram and on_disk_payload flags are deprecated in favour of the unified memory tiers. [15]

Limits

Dense vectors and the HNSW index are cached in RAM by default, so memory grows linearly with vectors × dimensions. Quantization or the cold tier cut RAM at some cost to recall or latency; the presets assume neither. [11][15]
Storage must be a local block device with a POSIX file system, preferably SSD or NVMe. NFS and object storage such as S3 do not work. [1]
This is a single node: no replication or high availability, and every upgrade has a short downtime. Upstream recommends at least three nodes and replication factor 2 for production HA. [1][11][13]
Restoring a snapshot needs twice the disk the collection uses, and snapshots kept in /qdrant/snapshots stay on the same disk until they are deleted. [9][11]

Security

A self-hosted Qdrant has no authentication by default and binds to all interfaces. This template always sets an admin API key; send it only over HTTPS, since a key on plain HTTP can be sniffed. [4][6]
Give apps that only query a read-only key (QDRANT__SERVICE__READ_ONLY_API_KEY) or per-collection JWTs (jwt_rbac) rather than the admin key. [6]
Snapshot recovery from a URL makes Qdrant fetch that URL (an SSRF path); set enable_snapshot_url_recovery to false if not needed. Anonymous usage telemetry is on unless telemetry_disabled is true. [4][6]

Backup

Back up with snapshots: a full storage snapshot (POST /snapshots) on a single node, or per-collection snapshots; download them and keep them off the server. A full storage snapshot is restored at start with ./qdrant --storage-snapshot. [9]
A snapshot restores only into the same or the next minor version, so take a fresh one before every upgrade and keep the one from before it. [9][13]