ScyllaDB University Live | Free Virtual Training Event
Learn more
ScyllaDB Documentation Logo Documentation
  • Deployments
    • Cloud
    • Server
  • Tools
    • ScyllaDB Manager
    • ScyllaDB Monitoring Stack
    • ScyllaDB Operator
  • Drivers
    • CQL Drivers
    • DynamoDB Drivers
    • Supported Driver Versions
  • Resources
    • ScyllaDB University
    • Community Forum
    • Tutorials
Install
Search Ask AI
ScyllaDB Docs ScyllaDB Operator Upgrade Upgrading ScyllaDB clusters

Caution

You're viewing documentation for an unstable version of ScyllaDB Operator. Switch to the latest stable version.

Upgrading ScyllaDB clusters¶

Upgrading your ScyllaDB cluster to a newer version is automated by ScyllaDB Operator and performed using a rolling update strategy to maintain availability. It is as simple as updating the ScyllaDB image reference in your ScyllaDB cluster specification.

Warning

While the cluster remains operational throughout the process, applications requiring strict consistency levels (such as QUORUM) may experience transient unavailability. This can occur if the cluster topology view has not yet fully converged across all nodes before the next node is restarted.

We recommend scheduling upgrades during periods of low application traffic to minimize potential disruptions.

Issue tracking fix for this behavior: scylla-operator #1077.

Warning

ScyllaDB version upgrades must be performed consecutively, meaning you must not skip any major or minor version on the upgrade path. Before upgrading to the next version, ensure the entire ScyllaDB cluster has been successfully upgraded. For details, refer to the Upgrade procedure in ScyllaDB’s documentation.

Caution

Before upgrading ScyllaDB, ensure the target version is supported by the version of ScyllaDB Operator you are using. Refer to the support matrix for information on version compatibility.

Upgrade via GitOps (kubectl)¶

To upgrade your ScyllaDB cluster using GitOps (kubectl), adjust the ScyllaDB image tag/reference to the target one in your ScyllaDB cluster specification and re-apply the manifest.

apiVersion: scylla.scylladb.com/v1
kind: ScyllaCluster
metadata:
  name: scylladb
spec:
  version: 2026.1.3 # Specify the target ScyllaDB image tag.
  # ...

After reapplying the manifest, wait for your ScyllaCluster to roll out.

kubectl wait --for='condition=Progressing=False' scyllacluster.scylla.scylladb.com/scylladb
kubectl wait --for='condition=Degraded=False' scyllacluster.scylla.scylladb.com/scylladb
kubectl wait --for='condition=Available=True' scyllacluster.scylla.scylladb.com/scylladb
apiVersion: scylla.scylladb.com/v1alpha1
kind: ScyllaDBCluster
metadata:
  name: dev-cluster
spec:
  scyllaDB:
    image: docker.io/scylladb/scylla:2026.1.3 # Specify the target ScyllaDB image reference.
  # ...

After reapplying the manifest, wait for your ScyllaDBCluster to roll out.

kubectl --context=${CONTROL_PLANE_CONTEXT} wait --for='condition=Progressing=False' scylladbcluster.scylla.scylladb.com/dev-cluster
kubectl --context=${CONTROL_PLANE_CONTEXT} wait --for='condition=Degraded=False' scylladbcluster.scylla.scylladb.com/dev-cluster
kubectl --context=${CONTROL_PLANE_CONTEXT} wait --for='condition=Available=True' scylladbcluster.scylla.scylladb.com/dev-cluster

To verify the cluster state, execute nodetool status in each of the ScyllaDB cluster pods:

NAMESPACE=<namespace>
CLUSTER_NAME=<cluster-name>

# List all ScyllaDB pods in the cluster.
pods=$(kubectl -n "${NAMESPACE}" get pods \
    -l scylla/cluster="${CLUSTER_NAME}" \
    -l scylla-operator.scylladb.com/pod-type=scylladb-node \
    -o name)

# Execute nodetool status in each pod.
for pod in $pods; do
    kubectl -n "${NAMESPACE}" exec "${pod}" -c scylla -- nodetool status
done

All nodes should report all other nodes as UN (Up and Normal) in the output, e.g.:

Datacenter: us-east-1
===========================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address        Load    Tokens Owns Host ID                              Rack      
UN 10.221.135.48  3.30 KB 256    ?    5dd7f301-62d7-4ab7-986a-e7ea9d21be4d us-east-1a
UN 10.221.140.203 3.48 KB 256    ?    2f725f88-33fa-4ca7-b366-fa35e63e7c72 us-east-1b
UN 10.221.150.121 3.67 KB 256    ?    7063a262-fa3f-4f69-8a60-720f464b1483 us-east-1c

Upgrade via Helm¶

Important

ScyllaDB Operator does not yet support Helm installation path for managed multi-datacenter ScyllaDB clusters.

To upgrade your ScyllaDB cluster using Helm, upgrade your Helm release with the target ScyllaDB image tag/reference.

helm upgrade scylla scylla/scylla --reuse-values --set=scyllaImage.tag=2026.1.3

After upgrading the release, wait for your ScyllaCluster to roll out.

kubectl wait --for='condition=Progressing=False' scyllacluster.scylla.scylladb.com/scylladb
kubectl wait --for='condition=Degraded=False' scyllacluster.scylla.scylladb.com/scylladb
kubectl wait --for='condition=Available=True' scyllacluster.scylla.scylladb.com/scylladb

To verify the cluster state, execute nodetool status in each of the ScyllaDB cluster pods:

NAMESPACE=<namespace>
CLUSTER_NAME=<cluster-name>

# List all ScyllaDB pods in the cluster.
pods=$(kubectl -n "${NAMESPACE}" get pods \
    -l scylla/cluster="${CLUSTER_NAME}" \
    -l scylla-operator.scylladb.com/pod-type=scylladb-node \
    -o name)

# Execute nodetool status in each pod.
for pod in $pods; do
    kubectl -n "${NAMESPACE}" exec "${pod}" -c scylla -- nodetool status
done

All nodes should report all other nodes as UN (Up and Normal) in the output, e.g.:

Datacenter: us-east-1
===========================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address        Load    Tokens Owns Host ID                              Rack      
UN 10.221.135.48  3.30 KB 256    ?    5dd7f301-62d7-4ab7-986a-e7ea9d21be4d us-east-1a
UN 10.221.140.203 3.48 KB 256    ?    2f725f88-33fa-4ca7-b366-fa35e63e7c72 us-east-1b
UN 10.221.150.121 3.67 KB 256    ?    7063a262-fa3f-4f69-8a60-720f464b1483 us-east-1c

Was this page helpful?

PREVIOUS
Upgrading ScyllaDB Operator
NEXT
Troubleshoot
  • Create an issue
  • Edit this page

On this page

  • Upgrading ScyllaDB clusters
    • Upgrade via GitOps (kubectl)
    • Upgrade via Helm
ScyllaDB Operator
Search Ask AI
  • master
    • master
    • v1.21
    • v1.20
    • v1.19
    • v1.18
  • Get Started
    • What Is ScyllaDB Operator?
    • ScyllaDB Concepts on Kubernetes
  • Install Operator
    • Provision infrastructure
      • Set up a GKE cluster for ScyllaDB
      • Set up an EKS cluster for ScyllaDB
      • Set up an OKE cluster for ScyllaDB
      • Set up an OpenShift cluster for ScyllaDB
    • Install with GitOps
    • Install with Helm
    • Install on OpenShift
  • Deploy ScyllaDB
    • Before you deploy
      • Set up dedicated node pools
      • Configure CPU pinning
      • Configure nodes
      • Configure ScyllaDB Operator
    • Deploy your first cluster
    • Reference deployments
      • Reference deployment: GKE
      • Reference deployment: EKS
      • Reference deployment: OKE
      • Reference deployment: OpenShift
    • Install ScyllaDB Manager
    • Set up networking
      • Configure external access
      • IPv6 networking
        • Getting started with IPv6 networking
        • Configure dual-stack networking
        • Configure IPv6-only networking
        • Migrate clusters to IPv6
        • Troubleshoot IPv6 networking issues
        • IPv6 networking concepts
    • Set up monitoring
      • Set up ScyllaDB Monitoring
      • Set up ScyllaDB Monitoring on OpenShift
      • Expose Grafana
    • Production checklist
  • Connect Your App
    • Connect via CQL
    • Alternator (DynamoDB API)
    • Discovery endpoint
  • Understand
    • Storage
    • Tuning
    • ScyllaDB Manager
    • Networking
    • ScyllaDB Monitoring overview
    • Bootstrap synchronisation
    • Automatic data cleanup
    • Sidecar and pod anatomy
    • Ignition
    • Pod disruption budgets
    • Security
    • StatefulSets and racks
  • Operate
    • Scale, add, remove racks
    • Replace nodes
    • Expand storage volumes
    • Use maintenance mode
    • Back up and restore
    • Restore from backup
    • Perform a rolling restart
    • Migrate a rack to a new node pool
    • Pass additional ScyllaDB arguments
    • Configure precomputed IO properties
  • Upgrade
    • Upgrading ScyllaDB Operator
    • Upgrading ScyllaDB clusters
  • Troubleshoot
    • Investigate pod restarts
    • Change log level on a live cluster
    • Recover from a failed node replace
    • Troubleshoot performance
    • Collect debugging information
      • Collect data with must-gather
      • must-gather contents
      • Query system tables for debugging
    • Collect core dumps
  • Reference
    • API Reference
      • scylla.scylladb.com
        • NodeConfig (scylla.scylladb.com/v1alpha1)
        • RemoteKubernetesCluster (scylla.scylladb.com/v1alpha1)
        • RemoteOwner (scylla.scylladb.com/v1alpha1)
        • ScyllaCluster (scylla.scylladb.com/v1)
        • ScyllaDBCluster (scylla.scylladb.com/v1alpha1)
        • ScyllaDBDatacenterNodesStatusReport (scylla.scylladb.com/v1alpha1)
        • ScyllaDBDatacenter (scylla.scylladb.com/v1alpha1)
        • ScyllaDBManagerClusterRegistration (scylla.scylladb.com/v1alpha1)
        • ScyllaDBManagerTask (scylla.scylladb.com/v1alpha1)
        • ScyllaDBMonitoring (scylla.scylladb.com/v1alpha1)
        • ScyllaOperatorConfig (scylla.scylladb.com/v1alpha1)
    • Feature gates
    • IPv6 configuration reference
    • Releases
    • Known issues
    • Conditions reference
    • nodetool alternatives
  • Contributing to ScyllaDB Operator
Docs Tutorials University Contact Us About Us
© 2026, ScyllaDB. All rights reserved. | Terms of Service | Privacy Policy | ScyllaDB, and ScyllaDB Cloud, are registered trademarks of ScyllaDB, Inc.
Last updated on 22 May 2026.
Powered by Sphinx 9.1.0 & ScyllaDB Theme 1.9.2