Multi-database support in cluster mode

commands/cluster-countkeysinslot.md

@@ -1,7 +1,8 @@
-Returns the number of keys in the specified Valkey Cluster hash slot. The
-command only queries the local data set, so contacting a node
-that is not serving the specified hash slot will always result in a count of
-zero being returned.
+Returns the number of keys in the specified Valkey Cluster hash slot **in the
+currently selected database**. The command only queries the local data set, 
+so contacting a node that is not serving the specified hash slot will always 
+result in a count of zero being returned.
+
 
 ```
 > CLUSTER COUNTKEYSINSLOT 7000

commands/cluster-getkeysinslot.md

@@ -1,7 +1,7 @@
-The command returns an array of keys names stored in the contacted node and
-hashing to the specified hash slot. The maximum number of keys to return
-is specified via the `count` argument, so that it is possible for the user
-of this API to batch-processing keys.
+The command returns an array of key names stored in the contacted node and
+hashing to the specified hash slot **in the currently selected database**. 
+The maximum number of keys to return is specified via the `count` argument, 
+so that it is possible for the user of this API to batch-process keys.
 
 The main usage of this command is during rehashing of cluster slots from one
 node to another. The way the rehashing is performed is exposed in the Valkey

commands/migrate.md

@@ -18,9 +18,13 @@ deletes the key using `DEL`.
 The timeout specifies the maximum idle time in any moment of the communication
 with the destination instance in milliseconds.
 This means that the operation does not need to be completed within the specified
-amount of milliseconds, but that the transfer should make progresses without
+amount of milliseconds, but that the transfer should make progress without
 blocking for more than the specified amount of milliseconds.
 
+`MIGRATE` operates on the database currently selected in the connection.
+Before calling `MIGRATE`, you can switch databases using `SELECT <dbid>`,
+and the command will migrate keys from that database.
+
 `MIGRATE` needs to perform I/O operations and to honor the specified timeout.
 When there is an I/O error during the transfer or if the timeout is reached the
 operation is aborted and the special error - `IOERR` returned.

commands/select.md

@@ -5,6 +5,6 @@ Selectable Valkey databases are a form of namespacing: all databases are still p
 
 In practical terms, Valkey databases should be used to separate different keys belonging to the same application (if needed), and not to use a single Valkey instance for multiple unrelated applications.
 
-When using Valkey Cluster, only `SELECT 0` can be used, since Valkey Cluster only supports database zero. In the case of a Valkey Cluster, having multiple databases would be useless and an unnecessary source of complexity. Commands operating atomically on a single database would not be possible with the Valkey Cluster design and goals.
+Valkey Cluster now allows multiple databases. You can use `SELECT 0`  <dbid> to switch between them.
 
 Since the currently selected database is a property of the connection, clients should track the currently selected database and re-select it on reconnection. While there is no command in order to query the selected database in the current connection, the `CLIENT LIST` output shows, for each client, the currently selected database.

commands/swapdb.md

@@ -1,6 +1,12 @@
 This command swaps two Valkey databases, so that immediately all the
 clients connected to a given database will see the data of the other database, and
-the other way around. Example:
+the other way around. 
+
+**Note:** `SWAPDB` is **disabled in cluster mode** to prevent shard inconsistencies, 
+as swapping databases on one shard while leaving others unchanged could lead to 
+data inconsistencies.
+
+Example:
 
     SWAPDB 0 1
 

topics/cluster-spec.md

@@ -31,8 +31,8 @@ to force certain keys to be stored in the same hash slot. However, during
 manual resharding, multi-key operations may become unavailable for some time
 while single-key operations are always available.
 
-Valkey Cluster does not support multiple databases like the standalone version
-of Valkey. We only support database `0`; the `SELECT` command is not allowed.
+Valkey Cluster now supports multiple databases, similar to standalone mode. 
+The `SELECT` command can be used to switch databases.
 
 ## Client and Server roles in the Valkey cluster protocol