Skip to content
Stackship documentation Svenska

Vector stores (Qdrant)Users

Manage a vector store

Change a vector store's version, plan and replicas, open it to the outside, rotate its API key, stop or start it, back up a collection, and delete it.

Requires: qdrantcluster/write, qdrantcluster/writeSecrets

Open Vector Store in the sidebar and choose the vector store. Its header shows the status and, while it is Running, Restart and Stop; while it is Stopped, Start. The tabs are Overview, Configuration (shown to people who may change the vector store), Access Control, Revisions, Operations, Activity and Danger Zone (shown to people who may delete it). Changes need qdrantcluster/write; rotating the API key also needs qdrantcluster/writeSecrets.

The overview

Card What it shows
Database Server Name, resource group, boundary, cluster, Version and status
Security API Key Auth — whether API key authentication is on
Scaling & Resources Replicas, Ready Replicas, and the CPU, memory and storage of each server
Connection Details The endpoints and the API key — see Connect to a vector store

Runtime

Configuration → Runtime holds three settings; choose Save to apply them.

  • Version — the tag of the qdrant/qdrant image the servers run, such as v1.13.2. It must start with a version number (v1.13.2 or 1.13.2). The platform offers no list of versions: pick a tag from Qdrant's releases. Saving a new version replaces the servers with ones running it.
  • Compute Plan — changing it gives every server the plan's CPU and memory, and sets the replica count to the plan's, unless you change Replicas in the same save. The servers are replaced to take the new resources. The storage size stays what it was.
  • Replicas — see below.

Change the replica count

Replicas takes 1 to 5. With the CLI, stsh qdrant scale does the same and needs qdrantcluster/scale.

  • Adding replicas starts more servers, which join the cluster empty. Qdrant does not move existing shards onto them; collections created afterwards spread over all servers. Use Qdrant's cluster API to move shards if you want existing collections to use the new servers.
  • Removing replicas stops the highest-numbered servers without moving their shards away first. A collection with shards on those servers and no copies elsewhere loses access to that part of its data. Move the shards off those servers with Qdrant's cluster API before you scale down.

How shards and copies work is explained in Replicas and sharding.

Networking and the API key

Configuration → Networking & Security has three parts. Choose Save after changing the first two.

External access

  • Enable load balancer — gives the vector store an address outside the Kubernetes cluster that serves the REST (6333) and gRPC (6334) ports, without TLS. External endpoint shows http://<address>:6333 once the address is assigned, and Waiting for a load balancer address… until then.
  • Enable HTTPS ingress — serves the REST API and the dashboard over HTTPS on a hostname, with a managed certificate. Hostname is the hostname served; leave it empty for the platform hostname, and clear a custom hostname to go back to it. A custom hostname needs a DNS record that points it at the platform's ingress.
  • Allowed CIDR blocks — a comma-separated list such as 10.0.0.0/16, 203.0.113.0/24. It limits the load balancer to those source addresses, and the HTTPS ingress too on installations whose ingress controller is NGINX. Empty allows any source. It applies only while the load balancer or the HTTPS ingress is on.

Both switches are disabled while API key authentication is off, and the platform refuses to save either exposure without it. Turning the HTTPS ingress on is also refused when your installation has no certificate issuer for it, or when Hostname is empty and your installation has no Qdrant domain.

API Key Authentication

Enable API Key Auth decides whether clients must send the API key. Turning it off is refused while the load balancer or the HTTPS ingress is on. With it off, any workload that can reach the vector store can read, change and delete its data.

Rotate the API key

API Key Rotation, at the bottom of Configuration → Networking & Security, has Rotate API Key while API key authentication is on. It needs qdrantcluster/writeSecrets and qdrantcluster/write.

  1. Choose Rotate API Key. The new key is shown in the section; copy it. You can also show it later on the Overview.
  2. The platform restarts the servers so that they use the new key. A server accepts the old key until it has restarted, and a vector store with one replica is unavailable while its server restarts.
  3. Put the new key wherever clients keep it — for workloads, in the vault secret — and restart those workloads.

The section's own text says that rotation causes no downtime, that the old key stops working at once and that the new key is not shown again. The steps above describe what happens instead.

Performance settings

Configuration → Performance shows fields for the HNSW index, the optimizer, quantization and the write-ahead log.

Warning

These fields are not applied. Saving them reports success but changes nothing on the servers, and the fields are empty again when you reopen the section. Set these parameters per collection with Qdrant's API instead, when you create or update the collection.

Stop, start and restart

  • Stop remembers the replica count and stops every server. The volumes and their data stay; the vector store shows Stopped and cannot be reached.
  • Start brings back the remembered number of servers, or one when there is none to remember.
  • Restart completes without replacing any server, so it does not restart the vector store. To restart the servers, choose Stop and then Start.

Back up a collection

The platform keeps no backups of a vector store. Qdrant's snapshot API makes a file of one collection that you can download and keep:

bash
curl -X POST -H "api-key: $QDRANT_API_KEY" https://<hostname>/collections/<collection>/snapshots
curl -H "api-key: $QDRANT_API_KEY" -o <collection>.snapshot \
  https://<hostname>/collections/<collection>/snapshots/<snapshot-name>

The first call returns the snapshot's name. Download it straight away: the servers keep snapshots on temporary storage that is emptied when a server restarts. On a vector store with more than one replica, Qdrant takes snapshots on each server separately, and the vector store's endpoints do not let you choose the server, so this captures a whole collection only on a vector store with one replica.

Delete a vector store

On the Danger Zone tab, choose Delete and type the vector store's name to confirm. This needs qdrantcluster/delete, which qdrantcluster/write includes. The servers, the endpoints and the API key are removed.

Important

The servers' volumes are not deleted. They stay in the resource group, with their data, until the resource group is deleted, and a new vector store with the same name in the same resource group takes them over — data included.

With the CLI

bash
stsh qdrant get my-vectors -g my-resource-group
stsh qdrant update my-vectors -g my-resource-group --set qdrantVersion=v1.14.0
stsh qdrant scale my-vectors -g my-resource-group --replicas 3
stsh qdrant stop my-vectors -g my-resource-group
stsh qdrant start my-vectors -g my-resource-group
stsh qdrant delete my-vectors -g my-resource-group

The API key is rotated through the API:

bash
stsh api POST /boundaries/<boundary-id>/resourcegroups/<resource-group>/resources/qdrantclusters/<name>/apikey/rotate