Manage PostgreSQL Error: remaining connection slots are reserved for non-replication superuser connections. sorry, too many clients already

Posted July 30, 2021 1.2k views
Node.jsPostgreSQLDatabasesDigitalOcean Managed PostgreSQL DatabaseStrapi

I explored DigitalOceans Managed Databases particularly PostgreSQL as a means to simplify development and save time although I found that very frequently there would be the following error:

Error: remaining connection slots are reserved for non-replication superuser connections. sorry, too many clients already

I noticed that this error would occur quite frequently regardless of what was invoking the database for example as to whether a tool like DataGrip / PgAdmin were being used or the backend server. At first I thought it was related to the backend server until I started getting the error within DataGrip additionally.

We’re using Strapi and PostgreSQL, with 3 developers working on this simultaneously.

I’ve explored using connection pooling although have had the following error with both database tool and server:

cross database references are not implemented

I’ve now explored creating and hosting my own PostgreSQL database on a DigitalOcean Ubuntu droplet and the error no longer seems to occur.

So whilst I’ve found a solution or workaround, I am interested as to why this error occurs with DigitalOcean Managed PostgreSQL Database.

Thanks for your help :)


These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
1 answer


Each PostgreSQL cluster allows 25 backend connections per 1 GB of RAM minus 3 connections per node that are reserved for maintenance.

Here is a quick overview of the allowed backend connections based on each plan:

Plan Size Available Backend Connections
1 GB RAM 22
2 GB RAM 47
4 GB RAM 97
8 GB RAM 197
16 GB RAM 397
32 GB RAM 797
64 GB RAM 1,597

Connection pooling is also supported, backed by PgBouncer, to increase the number of available concurrent client connections. However, these PgBouncer pool connections are currently limited to 20 per database.

Hope that this helps.

  • Hi Bobby,

    Thanks for your response here :)

    I’m hosting my own PostgreSQL for database and there hasn’t been any problems as of yet. I imagine with Managed PostgreSQL databases, you’d need to have quite a number of connections then because we were experiencing this issue just in development. I thought the minimal machine type and node plan would be sufficient for development with at most 3 different developers.

    Like I mentioned the error occurred in multiple places include Strapi API and DataGrip.

    At this current time, I didn’t seem to be able to use connection pooling though with Strapi or DataGrip due to following error:

    cross database references are not implemented

    I’m hosting my own PostgreSQL database on an Ubuntu Digtal Ocean droplet and it is working fine.

    I’d be interested in finding out more about this as to why there are no error when I host my own database but there when I use the managed database. I appreciate you’ve mentioned the connection pooling but I would expect that minimal config for development to be sufficient.


    Thanks for your response and your help here :)


    • Hello,

      Regarding the connections error, with a self-hosted PostgreSQL database, the default max connections value is typically 100 connections. With a Managed PostgreSQL with 1GB RAM, the limit is 22.

      So if you have more than 22 simultaneous connections this would explain the problem with the Managed Database cluster and not the self-hosted one.

      Regarding the connection pooling error, what I could suggest is, if you want to join multiple tables, you could put them into different schemas in one database rather than into different databases.

      Let me know how it goes.

      • Hi Bobby,

        Thanks so much for going into these details further - really appreciate that!

        Well either that, or too many connections are being created and not closed by the server? Perhaps, this might be different if I was able to enable connection pooling?

        Okay great, thanks for your suggestion here :)

        Of course, will revisit this soon.

        Thanks again for your help,