Cleanup and clearer info

product_docs/docs/biganimal/release/getting_started/creating_a_cluster/creating_a_dha_cluster.mdx

@@ -65,7 +65,7 @@ The following options aren't available when creating your cluster:
 
      For more information on node architecture, see [Distributed high availability](../../overview/02_high_availability/distributed_highavailability/).
 
-1.  In the **Provider & Region** section, select the cloud provider and region where you want to deploy your cluster. If you're using your account and haven't connected it to BigAnimal yet, see [Connecting to your cloud](/biganimal/latest/getting_started/02_connecting_to_your_cloud)
+1.  In the **Provider & Region** section, select the cloud provider and region where you want to deploy your cluster.
 
     !!! Tip
         For the best performance, we strongly recommend that this region be the same as your other resources that communicate with your cluster. For a list of available regions, see [Supported regions](../../overview/03a_region_support). If you're interested in deploying a cluster to a region that isn't currently available, contact [Support](/biganimal/latest/overview/support/). 
@@ -133,6 +133,7 @@ The following options aren't available when creating your cluster:
     In **Volume Properties**, select the disk size for your cluster.
 
     </details>
+    <br/>
 
     !!!note Note for all cloud providers
        When provisioning database storage, not all of the storage space you specify is available for holding your data. Some space is reserved for other purposes. For a full explanation of the structure of a Postgres data directory, see [Database File Layout](https://www.postgresql.org/docs/current/storage-file-layout.html). You can make more storage space available for data if you specify separate storage for WAL. 
@@ -167,7 +168,7 @@ The following options aren't available when creating your cluster:
 
 1. In the **Connections** section: 
 
-   Enable **Read-only Workloads**. This feature configures a connection string you can use to perform read-only operations to shadow nodes (non-write leaders) to lighten the workload on the write leader and improve the PGD cluster's performance.
+   When enabled, the **Read-only Workloads** option configures a connection string you can use for read-only operations. This connection enables shadow nodes (non-write leaders) to handle all read-only operations with the goal of lightening the workload on the write leader and improving the cluster's performance.
 
    If this option is enabled, you might have to raise the IP address resource limits for the cluster:
 
@@ -177,12 +178,13 @@ The following options aren't available when creating your cluster:
 
    !!! Important 
 
-       When configuring a read-only connection string with your application, read-only workloads are routed to shadow nodes (non-write leaders). The connection is read-only because it accepts read-only queries through the shadow nodes. However, commands that run on read-only connections aren't filtered by BigAnimal, so shadow nodes can still perfom write operations to the contents of database tables. We recommend that you use a Postgres role with minimal read-only privileges for your application. This way, you can avoid write operations on shadow nodes that could cause conflicts between the write leader and the shadow nodes. 
+       When configuring a read-only connection string with your application, read-only workloads are routed to shadow nodes (non-write leaders). The connection is read-only because it accepts read-only queries through the shadow nodes. However, commands that run on read-only connections aren't filtered by BigAnimal, so shadow nodes can still perfom write operations to the contents of database tables. We recommend that you use a Postgres role with minimal read-only privileges for your application or pass `default_transaction_read_only=on` in the connection string. This way, you can avoid write operations on shadow nodes that could cause conflicts between the write leader and the shadow nodes. 
+       See [PGD Proxy read-only routing rules](/pgd/latest/routing/readonly/) for more information.
 
    !!! Note
        Advisory locks aren't replicated between Postgres nodes, so advisory locks taken on a shadow node don't conflict with advisory locks taken on the lead. We recommend that applications that rely on advisory locking avoid using read-only workloads for those transactions.
 
-    See [Read-only workloads](../../overview/02_high_availability/distributed_highavailability/#read-only-workloads) for more information about read-only connections on BigAnimal. 
+    See [Read-only workloads](../../overview/02_high_availability/distributed_highavailability/#read-only-workloads) for more information about read-only connections on Distributed High Availability clusters.
 
 1. Select **Next: DB Configuration**
 

product_docs/docs/biganimal/release/overview/02_high_availability/distributed_highavailability.mdx

@@ -59,9 +59,15 @@ Cross-cloud service provider witness nodes are available with AWS, Azure, and Go
 
 ## Read-only workloads
 
-When you enable read-only workloads, a read-only connection string is created. You can use this connection to route read-only requests through the shadow nodes (non-write leaders) to lighten the load on the write leaders. In a two-node cluster, the single shadow node serves read-only workloads. In a three-node cluster, the two shadow nodes serve read-only workloads, unless a witness node is enabled. In a three-node cluster with a witness, read-only workloads are served by the single shadow node only.
+When you enable the read-only workloads option during the cluster creation, a read-only connection string is created for the data group. You can use this connection to allow your application or service to route read-only requests through the shadow nodes (non-write leaders) to lighten the load on the write leaders and improve the Distributed High Availability cluster's performance. 
 
-Similarly, if you have three data groups, the witness group will not serve any data requests. You can choose whether to enable read-only connections on the other two data groups, or just on one.
+If you have more than one data group, you can choose whether to enable the read-only workloads option on a per-data-group basis. 
+
+Since the infrastructure of a Distributed High Availability cluster is almost entirely based on EDB Postgres Distributed, the same [PGD Proxy read-only routing rules](/pgd/latest/routing/readonly/) apply.
+
+!!! Important 
+
+    When configuring a read-only connection string with your application, read-only workloads are routed to shadow nodes (non-write leaders). The connection is read-only because it accepts read-only queries through the shadow nodes. However, commands that run on read-only connections aren't filtered by BigAnimal, so shadow nodes can still perfom write operations to the contents of database tables. We recommend that you use a Postgres role with minimal read-only privileges for your application or pass `default_transaction_read_only=on` in the connection string. This way, you can avoid write operations on shadow nodes that could cause conflicts between the write leader and the shadow nodes. 
 
 ## For more information