diff --git a/website/content/docs/install-boundary/architecture/high-availability.mdx b/website/content/docs/install-boundary/architecture/high-availability.mdx
index 1a73fd32dd..8d50d94feb 100644
--- a/website/content/docs/install-boundary/architecture/high-availability.mdx
+++ b/website/content/docs/install-boundary/architecture/high-availability.mdx
@@ -16,7 +16,7 @@ The following ports should be available:
 - Clients must have access to the Controller's `api` port (default 9200)
 - Clients must have access to the Worker's port (default 9202)
 - Workers must have access to the Controller's `cluster` port (default 9201)
-- Workers must have a route and port access to the hosts defined within the system in order to provide connectivity
+- Workers must have a route and port access to the hosts defined within the system to provide connectivity
 
 ## Architecture
 
@@ -31,6 +31,14 @@ The workers must be able to establish a connection to the hosts with which they
 
 Boundary requires an external [Postgres](https://www.postgresql.org/) and [KMS](https://aws.amazon.com/kms/). In the example above, we're using AWS managed services for these components. For Postgres, we're using [RDS](https://aws.amazon.com/rds/) and for KMS we're using Amazon's [Key Management Service](https://aws.amazon.com/kms/).
 
+### Database
+
+Boundary controllers must be able to reach the PostgreSQL database.
+If you use a [high availability](/boundary/docs/install-boundary/high-availability) (HA) configuration, then the controllers must have access to the PostgreSQL server infrastructure.
+
+For more information about configuring the Postgres database for HA, refer to the [Postgres high availability, load balancing, and replication documentation](https://www.postgresql.org/docs/current/high-availability.html).
+If you use a managed service, refer to your provider's PostgreSQL high availability documentation.
+
 ### API and console load balancer
 
 Load balancing the controller allows operators to secure the ingress to the Boundary system. We recommend placing all Boundary servers in private networks and using load balancing techniques to expose services such as the API and administrative console to public networks. In the high availability architecture, we recommend load balancing using a layer 7 load balancer and further constraining ingress to that load balancer with layer 4 constraints such as [security groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) or [IP tables](https://wiki.archlinux.org/index.php/Iptables).
diff --git a/website/content/docs/install-boundary/architecture/system-requirements.mdx b/website/content/docs/install-boundary/architecture/system-requirements.mdx
index 4aeae51c57..e479bba4d2 100644
--- a/website/content/docs/install-boundary/architecture/system-requirements.mdx
+++ b/website/content/docs/install-boundary/architecture/system-requirements.mdx
@@ -145,6 +145,9 @@ If you use a [high availability](/boundary/docs/install-boundary/high-availabili
 In non-HA configurations, the Boundary servers must have access.
 Worker nodes never need access to the database.
 
+For more information about configuring the Postgres database for HA, refer to the [Postgres high availability, load balancing, and replication documentation](https://www.postgresql.org/docs/current/high-availability.html).
+If you use a managed service, refer to your provider's PostgreSQL high availability documentation.
+
 ### Database users and roles
 
 After the database has been initialized, the database user for a Boundary controller requires only permissions for [data manipulation](https://www.postgresql.org/docs/current/dml.html) operations (select, insert, update, and delete).