diff --git a/product_docs/docs/pgd/5.6/planning/limitations.mdx b/product_docs/docs/pgd/5.6/planning/limitations.mdx
index 1c45ed8a054..da273890431 100644
--- a/product_docs/docs/pgd/5.6/planning/limitations.mdx
+++ b/product_docs/docs/pgd/5.6/planning/limitations.mdx
@@ -24,18 +24,22 @@ into account when planning your deployment.
 
 ## Multiple databases on single instances
 
-Support for using PGD for multiple databases on the same Postgres instance is
-**deprecated** beginning with PGD 5 and will no longer be supported with PGD 6. As
-we extend the capabilities of the product, the added complexity introduced
-operationally and functionally is no longer viable in a multi-database design.
-
-It's best practice and we recommend that you configure only one database per PGD instance. 
-
-The deployment automation with TPA and the tooling such as the CLI
-and PGD Proxy already codify that recommendation. 
-
-While it's still possible to host up to 10 databases in a single instance,
-doing so incurs many immediate risks and current limitations:
+Support for running multiple instances of PGD on the same Postgres node is
+**deprecated** beginning with PGD 5, as the operational complexity of this
+approach is no longer viable.
+
+Future versions of PGD will eventually disallow running multiple instances of
+PGD. Instead, support for a single PGD installation hosting multiple databases
+is being planned.
+
+It's best practice and we recommend that you configure only one database per
+PGD instance. The deployment automation with TPA and the tooling such as the
+CLI and PGD Proxy already codify that recommendation. To separate tables into
+modules, the use of schemas is recommended in combination with PGD 5.
+
+While it's still possible to host up to 10 PGD enabled databases in a single
+Postgres instance, doing so incurs many immediate risks and current
+limitations:
 
 -   If PGD configuration changes are needed, you must execute administrative commands 
     for each database. Doing so increases the risk for potential
diff --git a/product_docs/docs/pgd/5/planning/limitations.mdx b/product_docs/docs/pgd/5/planning/limitations.mdx
index a2ef0148487..3659359abf6 100644
--- a/product_docs/docs/pgd/5/planning/limitations.mdx
+++ b/product_docs/docs/pgd/5/planning/limitations.mdx
@@ -23,20 +23,24 @@ into account when planning your deployment.
   details](architectures/#architecture-details).
 
 
-## Multiple databases on single instances
+## Multiple PGD instances per Postgres node
 
-Support for using PGD for multiple databases on the same Postgres instance is
-**deprecated** beginning with PGD 5 and will no longer be supported with PGD 6. As
-we extend the capabilities of the product, the added complexity introduced
-operationally and functionally is no longer viable in a multi-database design.
+Support for running multiple instances of PGD on the same Postgres node is
+**deprecated** beginning with PGD 5, as the operational complexity of this
+approach is no longer viable.
 
-It's best practice and we recommend that you configure only one database per PGD instance. 
+Future versions of PGD will eventually disallow running multiple instances of
+PGD. Instead, support for a single PGD installation hosting multiple databases
+is being planned.
 
-The deployment automation with TPA and the tooling such as the CLI
-and PGD Proxy already codify that recommendation. 
+It's best practice and we recommend that you configure only one database per
+PGD instance. The deployment automation with TPA and the tooling such as the
+CLI and PGD Proxy already codify that recommendation. To separate tables into
+modules, the use of schemas is recommended in combination with PGD 5.
 
-While it's still possible to host up to 10 databases in a single instance,
-doing so incurs many immediate risks and current limitations:
+While it's still possible to host up to 10 PGD enabled databases in a single
+Postgres instance, doing so incurs many immediate risks and current
+limitations:
 
 - If PGD configuration changes are needed, you must execute administrative commands 
   for each database. Doing so increases the risk for potential