Qdrant Version Upgrade

Qdrant has the following version compatibility rules Upgrading Qdrant:

Upgrade the cluster first, then the client SDKs, so the application never calls features the older server doesn't support. Keep the SDK within one minor version of the cluster; larger gaps might work but aren't tested. When crossing several minor versions, update the SDKs once the cluster reaches the target version.
Storage compatibility spans one minor version. Self-hosted clusters, single-node ones included, must step through every intermediate minor version and land on the latest patch of each: from 1.15 to 1.17, upgrade every node to the newest 1.16.x first. Qdrant Cloud chains the intermediate updates for you Updating Qdrant Cloud clusters.
A rolling upgrade (one node at a time) is zero-downtime only if every collection has a replication factor of 2 or higher. A single-node cluster, or any collection with a replication factor of 1, needs a short downtime window Replication factor.

For managing Qdrant version upgrades in Qdrant Cloud, you can use the qcloud CLI tool.

Pre-Upgrade Checklist

Back up first: It's recommended to take a backup or snapshot before updating to allow for rollbacks. If the upgrade fails or you need to revert, you can restore the pre-upgrade snapshot. Qdrant Cloud applies data migrations during upgrades, so there's no live downgrade. Snapshots Cloud backups
Check release notes for default and behavior changes, not just deprecations. Version upgrades may introduce changes to default settings, validation rules, or query behavior that can affect existing workloads even when APIs remain compatible.
Test your client app against the target server version first in a non-prod environment, and check SDK release notes for deprecated/removed methods before switching over.