How to increase the connection limit for the Google Cloud SQL Postgres database?

Question

The number of connections for Google Cloud SQL PostgreSQL databases is relatively low. Depending on the plan this is somewhere between 25 and 500, while the limit for MySQL in Google Cloud SQL is between 250 and 4000, reaching 4000 very quickly.

We currently have a number of trial instances for different customers running on Kubernetes and backed by the same Google Cloud SQL Postgres server. Each instance uses a separate set of database, roles and connections (one per service). We've already reached the limit of connections for our plan (50) and we're not even close to getting to the memory or cpu limits. Connection pooling seems not to be an option, because the connections are with different users. I'm wondering now why the limit is so low and if there's a way to increase the limit without having to upgrade to a more expensive plan.

Answer 1

It looks like google just released this as a beta feature. When creating or editing a database instance, you can add a flag called max_connections, where you can enter a new limit between 14 and 262143 connections.

Answer 2

There is a Feature request in the Public Issue Tracker to expose and hence control max_connections in PostgreSQL. This comment (I am reproducing it here) explains the reasons to set the number of connections the way it is now:

Per-tier max_connections is now fully rolled out. As shown on 
https://cloud.google.com/sql/faq#sizeqps, the limits are now:

Memory size, in GiB | Maximum concurrent connections
--------------------+-------------------------------
0.6 (db-f1-micro)   | 25
1.7 (db-g1-small)   | 50
3.75 up to 6        | 100
6 up to 7.5         | 150
7.5 up to 15        | 200
15 up to 30         | 250
30 up to 60         | 300
60 up to 120        | 400
120 and above       | 500

I understand your frustration about the micro/small instances having fewer than 100 
concurrent connections and the lack of control of this flag. We arrived at these values by 
taking the available RAM, reducing it by overhead, shared buffers, autovacuum memory and 
then dividing the remaining ram by typical per-connection memory and rounding off. This 
gives us the number of connections that can be used without risk of hitting out-of-memory 
condition
The basic premise of a fully managed service with an attached SLA is that we provide safe 
hosting. This is what motivates us using a max_connections that is safe against OOM.

Your option is, as you have discarded connection pooling, to use an instance with higher memory.

UPDATE:

As mentioned in a comment of the mentioned thread, there has been changes to the max connections settings, which are now:

Futhermore the defaults can now be overridden with flags, up to 260K connections.