update pool size, add vpc, remove beta (#2760)

use-timescale/services/connection-pooling.md

@@ -20,8 +20,6 @@ pooler is a great way to improve performance. For example, web, serverless, and
 IoT applications often use an event-based architecture where data is read or
 written from the database for very short amount of time.
 
-<Beta />
-
 Your application rapidly opens and closes connections while the pooler
 maintains a set of long-running connections to the database. This improves
 performance because the pooler open the connections in advance,  allowing the
@@ -83,7 +81,7 @@ you might need to add custom configurations for some cases such as
     ```
 
     Check the `statement_timeout` setting is correct for the `<MY_APP>` user:
-
+    ```
     tsdb=> show statement_timeout;
     ┌───────────────────┐
     │ statement_timeout │
@@ -140,29 +138,26 @@ postgres://<USERNAME>:<PASSWORD>@service.example.cloud.timescale.com:29303/tsdb_
 Make sure you check the Timescale console output for the correct connection
 string to use in your application.
 
-## Connection allocations
+## Connection pool sizes
 
 A connection pooler manages connections to both the database itself, and the
-client application.
-
-The number of database connections allocated in each pool is managed by the
-`max_connections` parameter set in the service. The pooler keeps allocating
-connections until 60% of the total `max_connections`. 45% of the
-`max_connections` parameter is used for the session pool, and the remaining 15%
-is available for the transaction pool.
-
-The connection pooler can then allocate connections for the client application.
-By default, up to 45% of `max_connections` is available for the session pool,
-and up to 100% of `max_connections` is available for the transaction pool.
-However, if you want to make use of all available connections stipulated by
-`max_connections`, you can connect directly instead.
-
-For example, if `max_connections` is set to 500, the maximum number of database
-connections is 300, or 60% of `max_connections`. For the client application, in
-session mode, the maximum number of connections is 225, which limits the total
-number of database connections to 225. In transaction mode, the maximum number
-of connections is 500, which limits the total number of database connections to
-75.
+client application. It keeps a fixed number of connections open with the
+database, while allowing clients to open and close connections. Clients can 
+request a connection from the session pool or the transaction pool. The 
+connection pooler will then allocate the connection if there is one free.
+
+The number of client connections allowed to each pool is proportional to the
+`max_connections` parameter set for the database. The session pool can have a 
+maximum of `max_connections - 17` client connections, while the transaction 
+pool can have a maximum of `(max_connections - 17) * 20` client connections. 
+
+Of the 17 reserved connections that are not allocated to either pool, 12 are 
+reserved for superuser by default, and another 5 for Timescale operations. 
+
+For example, if `max_connections` is set to 500, the maximum number of client 
+connections for your session pool is `483 (500 - 17)` and `9,660 (483 * 20)` for 
+your transaction pool. The default value of `max_connections` varies depending 
+on your service's compute size.
 
 ## Add a connection pooler
 
@@ -217,5 +212,10 @@ update your application to adjust the port it uses to connect to your service.
 
 </Procedure>
 
+### VPC and connection pooling
+VPCs are supported with connection pooling. It does not matter the order you 
+add the pooler or connect to a VPC. Your connection strings will automatically 
+be updated to use the VPC connection string.
+
 [cloud-login]: https://console.cloud.timescale.com
 [about-connection-pooling-types]: /use-timescale/:currentVersion:/services/connection-pooling#pool-types