What is the operational difference between a rolling upgrade of a replicated cluster and an in-place upgrade of a single-node deployment?

The fundamental difference is that a replicated cluster has redundancy, so you can upgrade one node at a time while the others continue to serve. A rolling upgrade takes each node out of service, upgrades it, restarts it, and waits for it to rejoin and catch up before moving to the next node. At any moment, the cluster has enough healthy replicas to serve traffic, so the upgrade is transparent to users. A single-node deployment has no redundancy, so upgrading it means stopping the process, upgrading, and restarting - during which the service is unavailable. The downtime is the sum of the stop time, the upgrade time, and the restart and warm-up time. For a single-node deployment, the only way to avoid downtime is to run two nodes (which makes it a cluster) or to use a managed service that handles the upgrade. The rolling upgrade is one of the main operational benefits of running a replicated cluster, and it is why production deployments use replication even when they do not need the read scaling.

The mechanism that makes a rolling upgrade safe is that Qdrant's replication and consensus handle the temporary loss of a node. When a node is taken out, the cluster detects it, promotes a replica if the node was a primary, and continues serving. The node is upgraded and restarted, rejoins the cluster, and catches up on missed writes via WAL replay or a snapshot transfer. The cluster waits for the node to be fully caught up before moving to the next. This is why the upgrade is slower than a single-node upgrade - it is paced by the catch-up time - but it is zero-downtime. The single-node upgrade has no such coordination: the process stops, and there is no replica to serve during the upgrade. The downtime can be reduced by pre-staging the new version and minimizing the restart time, but it cannot be eliminated. The difference in operational risk is significant: a rolling upgrade can be paused or rolled back if a node fails to rejoin, while a single-node upgrade has no fallback if the new version does not start.