Safe upgrade path from v1.15.x to v1.17.x now that RocksDB is removed?

[BittuChan]

I'm running a self-hosted Qdrant v1.15.2 cluster (3 nodes, ~5M vectors, 768 dimensions) on Kubernetes. I noticed the v1.17.0 release notes say RocksDB support is completely removed and direct upgrade from v1.15.x to v1.17.x won't work.

A few questions:

1. Is the required upgrade path strictly v1.15.x → v1.16.x → v1.17.x, or can I skip any intermediate patch versions?
2. During the v1.16.x step, does the Gridstore migration happen automatically on startup, or do I need to trigger it manually?
3. Is there any downtime during the migration on a distributed cluster, or does it happen rolling per-node?
4. How much additional disk space should I budget for during the migration (since both RocksDB and Gridstore data might coexist temporarily)?

My current setup:

• Qdrant v1.15.2 on K8s (StatefulSet, 3 replicas)
• ~5M points, 768-dim dense vectors with ~50 payload fields
• Using on_disk_payload: true

Suggested answer (from my research):
Based on the release notes and docs:

• You must go through v1.16.x first. The migration from RocksDB to Gridstore happens automatically on startup in v1.16.x for mutable segments as the Gridstore migration is active and runs in the background.
• On a distributed cluster, you can do a rolling update (one node at a time). Each node will migrate its own local shards on startup. There's no coordinated cluster-wide migration step.
• Budget roughly 1.5x–2x your current storage during migration, since RocksDB data and Gridstore data coexist until optimization compacts the segments. After optimization completes, Gridstore is typically more space-efficient.
• Make sure to take a snapshot before upgrading, and upgrade one minor version at a time as the release notes recommend.

Can someone confirm this, especially the disk space estimate?

[Shiven0504]

hey @BittuChan, After going through the release notes for v1.15, v1.16, and v1.17, the Gridstore blog post, and the upgrade documentation, here's what I found:

1. You cannot skip v1.16.x. The v1.16 release is what migrates your existing RocksDB-backed mutable payload indices and storage over to Gridstore. By the time v1.17 starts, it expects Gridstore exclusively if it encounters any remaining RocksDB storage, it will fail with an unsupported storage error.

2. When a v1.16.x node starts up, it actively migrates vector, payload, and payload index storage from RocksDB into Gridstore in the background (ref: PR #7551, PR #7433). No manual trigger is needed.

However, "automatic" doesn't mean "instant." The migration runs as part of the segment optimization process. For large collections, it may take some time for all segments to be fully optimized and migrated. You should monitor the optimization status via the collection info endpoint:
curl -s http://localhost:6333/collections/my_collection | jq '.result.optimizer_status'

3. Each node migrates only its own local shard replicas. There's no cluster-wide coordinated migration step. The Raft consensus layer handles the node temporarily being offline. With replication factor ≥ 2, reads and writes continue on the remaining nodes during each step.

Recommended K8s StatefulSet strategy:

spec:
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      partition: 0     # update all pods, one at a time
      maxUnavailable: 1
  minReadySeconds: 120   # give migration time before proceeding

Though honestly, for a critical migration like this, I'd recommend doing it manually pod-by-pod rather than relying on automated rollout.

[BittuChan]

Hii @Shiven0504, thanks for confirming! Just to summarize for anyone finding this later:
The key takeaway is: don't rush the v1.16 step.

The migration itself is hands-off, Qdrant handles RocksDB → Gridstore automatically on startup. The only real risk is jumping to v1.17 before all segments finish optimizing. So the single most important thing is -

# Run this on EVERY node before upgrading to v1.17
curl -s http://localhost:6333/collections/<name> | jq '.result.optimizer_status'
# Must return "ok", not "indexing"

Once that's green across all nodes, v1.17 upgrade is smooth.

For anyone on K8s, take snapshots first then do it pod-by-pod manually and make sure your PVs have ~50% headroom. The whole process took about 40 minutes for my 5M vector / 3-node cluster.