Regarding the Key Feature

One of the Key feature of CockroachDB is “ Eliminate planned downtime - Perform rolling upgrades of the database, operating systems, and machines. Run schema changes in the background, keeping applications online as you roll out new features. ”. Do you have more clarifications on the above statements. I got confused. What is meant by the statements.

Abdul Rahim

Hello Abdul,

Due to CockroachDB’s distributed nature upgrades, schema changes, or other maintenance actions can be performed without bringing down the entire cluster by performing these operations on some nodes while others continue to serve data. The particular details of these operations can be found in our docs, but this statement from our marketing page speaks to the resilient nature of CockroachDB as a distributed database.

Does that help to clarify?

Hello Nathan,

 I can understand.
  Say for example, we have 5 node cluster. If a node has some patching activities to be performed, in that context, only that node can be  detached form the cluster and perform the necessary actions on that node. Once the activities on the node is finished and add the nodes back in the same cluster. Since it is distributed, business continuity is still maintained. No outage to the application as the cluster is still functioning. Is that you mean to convey?

Is it possible to upgrade the version of CockorachDB in one node in the Cluster and others still have the older version. Would that entire cluster functioning normally?

Also one more statement would like to highlight “Run schema changes in the background” … What is meant by the statement ?
What all are Schema changes statements performed in the background?

Yes, I think your example of removing a node from the cluster to perform some patching activity is correct.

I don’t believe it is possible to have a node in a cluster running a different version of CockroachDB than the other nodes in the cluster. All the nodes should be running the same version.

By “in the background”, we mean that schema changes can be performed while the cluster is still serving an application. You can read more about it in our docs (

Hi Nathan,

Do you have any document which clearly says about cluster version upgrading?
Lets say, I have 5 - node cluster with version 19.0. I would like to upgrade the cluster to 20.2. In this context How can I perform? At what point the cluster version will be upgraded to 20.2. If quorum of nodes are upgraded to 20.2 in the rolling fashion and join backs to the cluster and the cluster version will automatically change to 20.2 ? or Any procedure for that? Say out of 5 nodes, 3 nodes are upgraded to 20.2. In this context what would be the Version of my cluster?
3 Node–>20.2
2 Node–>19.0


We do have docs about upgrading. If you are upgrading from version 19.1 you will need to first upgrade to version 20.1 and then upgrade to 20.2.

The docs to upgrade to 20.1 are here, and then docs to upgrade to 20.2 are here. If you perform a rolling upgrade (upgrading one node at a time) you will have a cluster that has nodes with different versions during the upgrade. The version of the cluster won’t change until all of the nodes have been upgraded.

This is the default behavior, but you can change this by disabling auto-finalization.

1 Like

Hi Nathan,

Let say, I have a 5 node cluster with 19.1 version. I have upgraded 3 nodes to 20.1.
At this point, Can I connect my application to the cluster? Would It throw any exception? As per your statement, the cluster is still in 19.1 version. So ideally it should work with 19.1 behavior correct ?
Mean Time if I do a rolling upgrades for the remaining 2 nodes and once its successful and joined back to the cluster, the cluster version will automatically be changed to 20.1 right ?
Assume I used the default settings.

In theory, everything you said is correct. In practice, if there isn’t an application connected to the cluster I was upgrading, I wouldn’t connect it to the cluster until the upgrade was finished.

You could also try it out locally by installing CockroachDB, starting a cluster, and then performing a rolling upgrade to see how it all works.

1 Like