Merge remote-tracking branch 'origin/cloud-2.0' into DOC-9723

src/current/_data/releases.yml

@@ -6672,13 +6672,6 @@
     docker_arm_limited_access: false
   source: true
   previous_release: v23.1.25
-  cloud_only: true
-  cloud_only_message_short: 'Available only for select CockroachDB Cloud clusters'
-  cloud_only_message: >
-    This version is currently available only for select
-    CockroachDB Cloud clusters. To request to upgrade
-    a CockroachDB self-hosted cluster to this version,
-    [contact support](https://support.cockroachlabs.com/hc/requests/new).
 
 - release_name: v23.2.11
   major_version: v23.2

src/current/_includes/v23.1/performance/reduce-hot-spots.md

@@ -2,17 +2,23 @@
 
 - Place parts of the records that are modified by different transactions in different tables. That is, increase [normalization](https://wikipedia.org/wiki/Database_normalization). However, there are benefits and drawbacks to increasing normalization.
 
-    - Benefits:
+    - Benefits of increasing normalization:
 
+        - Can improve performance for write-heavy workloads. This is because, with increased normalization, a given business fact must be written to one place rather than to multiple places.  
         - Allows separate transactions to modify related underlying data without causing [contention](#transaction-contention).
-        - Can improve performance for read-heavy workloads.
+        - Reduces the chance of data inconsistency, since a given business fact must be written only to one place.
+        - Reduces or eliminates data redundancy.
+        - Uses less disk space.
 
-    - Drawbacks:
+    - Drawbacks of increasing normalization:
 
+        - Can reduce performance for read-heavy workloads. This is because increasing normalization results in more joins, and can make the SQL more complicated in other ways.
         - More complex data model.
-        - Increases the chance of data inconsistency.
-        - Increases data redundancy.
-        - Can degrade performance for write-heavy workloads.
+
+    - In general:
+
+        - Increase normalization for write-intensive and read/write-intensive transactional workloads.
+        - Do not increase normalization for read-intensive reporting workloads.
 
 - If the application strictly requires operating on very few different index keys, consider using [`ALTER ... SPLIT AT`]({% link {{ page.version.version }}/alter-table.md %}#split-at) so that each index key can be served by a separate group of nodes in the cluster.
 

src/current/_includes/v23.2/performance/reduce-hot-spots.md

@@ -2,17 +2,23 @@
 
 - Place parts of the records that are modified by different transactions in different tables. That is, increase [normalization](https://wikipedia.org/wiki/Database_normalization). However, there are benefits and drawbacks to increasing normalization.
 
-    - Benefits:
+    - Benefits of increasing normalization:
 
+        - Can improve performance for write-heavy workloads. This is because, with increased normalization, a given business fact must be written to one place rather than to multiple places.  
         - Allows separate transactions to modify related underlying data without causing [contention](#transaction-contention).
-        - Can improve performance for read-heavy workloads.
+        - Reduces the chance of data inconsistency, since a given business fact must be written only to one place.
+        - Reduces or eliminates data redundancy.
+        - Uses less disk space.
 
-    - Drawbacks:
+    - Drawbacks of increasing normalization:
 
+        - Can reduce performance for read-heavy workloads. This is because increasing normalization results in more joins, and can make the SQL more complicated in other ways.
         - More complex data model.
-        - Increases the chance of data inconsistency.
-        - Increases data redundancy.
-        - Can degrade performance for write-heavy workloads.
+
+    - In general:
+
+        - Increase normalization for write-intensive and read/write-intensive transactional workloads.
+        - Do not increase normalization for read-intensive reporting workloads.
 
 - If the application strictly requires operating on very few different index keys, consider using [`ALTER ... SPLIT AT`]({% link {{ page.version.version }}/alter-table.md %}#split-at) so that each index key can be served by a separate group of nodes in the cluster.
 

src/current/_includes/v24.1/performance/reduce-hot-spots.md

@@ -2,17 +2,23 @@
 
 - Place parts of the records that are modified by different transactions in different tables. That is, increase [normalization](https://wikipedia.org/wiki/Database_normalization). However, there are benefits and drawbacks to increasing normalization.
 
-    - Benefits:
+    - Benefits of increasing normalization:
 
+        - Can improve performance for write-heavy workloads. This is because, with increased normalization, a given business fact must be written to one place rather than to multiple places.  
         - Allows separate transactions to modify related underlying data without causing [contention](#transaction-contention).
-        - Can improve performance for read-heavy workloads.
+        - Reduces the chance of data inconsistency, since a given business fact must be written only to one place.
+        - Reduces or eliminates data redundancy.
+        - Uses less disk space.
 
-    - Drawbacks:
+    - Drawbacks of increasing normalization:
 
+        - Can reduce performance for read-heavy workloads. This is because increasing normalization results in more joins, and can make the SQL more complicated in other ways.
         - More complex data model.
-        - Increases the chance of data inconsistency.
-        - Increases data redundancy.
-        - Can degrade performance for write-heavy workloads.
+
+    - In general:
+
+        - Increase normalization for write-intensive and read/write-intensive transactional workloads.
+        - Do not increase normalization for read-intensive reporting workloads.
 
 - If the application strictly requires operating on very few different index keys, consider using [`ALTER ... SPLIT AT`]({% link {{ page.version.version }}/alter-table.md %}#split-at) so that each index key can be served by a separate group of nodes in the cluster.
 

src/current/_includes/v24.2/performance/reduce-hot-spots.md

@@ -2,17 +2,23 @@
 
 - Place parts of the records that are modified by different transactions in different tables. That is, increase [normalization](https://wikipedia.org/wiki/Database_normalization). However, there are benefits and drawbacks to increasing normalization.
 
-    - Benefits:
+    - Benefits of increasing normalization:
 
+        - Can improve performance for write-heavy workloads. This is because, with increased normalization, a given business fact must be written to one place rather than to multiple places.  
         - Allows separate transactions to modify related underlying data without causing [contention](#transaction-contention).
-        - Can improve performance for read-heavy workloads.
+        - Reduces the chance of data inconsistency, since a given business fact must be written only to one place.
+        - Reduces or eliminates data redundancy.
+        - Uses less disk space.
 
-    - Drawbacks:
+    - Drawbacks of increasing normalization:
 
+        - Can reduce performance for read-heavy workloads. This is because increasing normalization results in more joins, and can make the SQL more complicated in other ways.
         - More complex data model.
-        - Increases the chance of data inconsistency.
-        - Increases data redundancy.
-        - Can degrade performance for write-heavy workloads.
+
+    - In general:
+
+        - Increase normalization for write-intensive and read/write-intensive transactional workloads.
+        - Do not increase normalization for read-intensive reporting workloads.
 
 - If the application strictly requires operating on very few different index keys, consider using [`ALTER ... SPLIT AT`]({% link {{ page.version.version }}/alter-table.md %}#split-at) so that each index key can be served by a separate group of nodes in the cluster.