# OperationalError: sorry, too many clients already

**URL:** <https://forum.djangoproject.com/t/operationalerror-sorry-too-many-clients-already/16221>\
**Category:** Deployment\
**Created:** [September 27, 2022, 10:03pm UTC](https://forum.djangoproject.com/t/operationalerror-sorry-too-many-clients-already/16221 "2022-09-27T22:03:20Z")\
**Posts on this page:** 14\
**Page:** 2

<div class="post-metadata">

**Author:** ![samul-1](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/samul-1/32/4767_2.png) [@samul-1](https://forum.djangoproject.com/u/samul-1)\
**Post date:** [October 20, 2022, 7:45pm UTC](https://forum.djangoproject.com/t/operationalerror-sorry-too-many-clients-already/16221/21 "2022-10-20T19:45:17Z")

</div>

Nope, I haven’t set that up yet. I have been trying everything else first because I believe that using pgbouncer would just mask the underlying cause.

Looking at the logs in postgres, it looks like the issue first appeared after switching from gunicorn to Daphne, on a day with a lot of traffic.

Now that I’ve gotten rid of channels, I think the next move could be to try and go back to gunicorn.

If that doesn’t work either, the last resort would be to use conn max age 0 and pgbouncer.

Looking at my output from pg\_stats, is there anything that jumps out to you? I have yet to understand how to interpret the values in the query column. To my understanding, they are the last query made by the connection before going idle?

---

<div class="post-metadata">

**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\
**Post date:** [October 20, 2022, 11:02pm UTC](https://forum.djangoproject.com/t/operationalerror-sorry-too-many-clients-already/16221/22 "2022-10-20T23:02:28Z")

</div>

The conversation from the other thread made it clear that you _need_ to set conn\_max\_age = 0. I’m not sure why you think it’s just going to “mask the underlying cause”.

Using pgbouncer will reduce (eliminate?) the latency involved in opening the connection each time.

---

<div class="post-metadata">

**Author:** ![samul-1](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/samul-1/32/4767_2.png) [@samul-1](https://forum.djangoproject.com/u/samul-1)\
**Post date:** [October 20, 2022, 11:04pm UTC](https://forum.djangoproject.com/t/operationalerror-sorry-too-many-clients-already/16221/23 "2022-10-20T23:04:57Z")

</div>

> [@KenWhitesell](#):
>
> you _need_ to set conn\_max\_age = 0

My understanding is that I need to do that if I’m using channels, right?

But under “normal” use, i.e. no channels, I would expect Django to properly close old connections.

> [@KenWhitesell](#):
>
> why you think it’s just going to “mask the underlying cause”.

Because I eliminated every usage of Channels, which allegedly was the culprit as it wasn’t closing the connections, and the issue still happened; therefore I assumed that if my app had some connection leak somewhere, using pgbouncer would only delay the issue.

Anyway, I switched back from daphne to gunicorn. We’ll see how it goes tomorrow with traffic.

---

<div class="post-metadata">

**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\
**Post date:** [October 20, 2022, 11:08pm UTC](https://forum.djangoproject.com/t/operationalerror-sorry-too-many-clients-already/16221/24 "2022-10-20T23:08:34Z")

</div>

You are still using Daphne. I don’t believe Channels, by itself, is the root cause. My impression from the other thread is that it’s a Daphne issue at its root.

---

<div class="post-metadata">

**Author:** ![samul-1](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/samul-1/32/4767_2.png) [@samul-1](https://forum.djangoproject.com/u/samul-1)\
**Post date:** [October 21, 2022, 5:01pm UTC](https://forum.djangoproject.com/t/operationalerror-sorry-too-many-clients-already/16221/25 "2022-10-21T17:01:24Z")

</div>

Well, after one day of using gunicorn with 5 workers, even while having slightly less than a hundred simultaneous users all sending concurrent requests, the number of connections never seemed to surpass 58.

I guess Daphne really was the cause of this.

---

<div class="post-metadata">

**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\
**Post date:** [October 28, 2022, 12:19pm UTC](https://forum.djangoproject.com/t/operationalerror-sorry-too-many-clients-already/16221/26 "2022-10-28T12:19:53Z")

</div>

To be accurate, it’s using Daphne with a conn\_max\_age \> 0 that is the cause. Daphne with conn\_max\_age = 0 shouldn’t exhibit this behavior.

---

<div class="post-metadata">

**Author:** ![marty0678](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/marty0678/32/13336_2.png) [@marty0678](https://forum.djangoproject.com/u/marty0678)\
**Post date:** [April 20, 2023, 6:17am UTC](https://forum.djangoproject.com/t/operationalerror-sorry-too-many-clients-already/16221/27 "2023-04-20T06:17:11Z")

</div>

Thanks for this thread, I’m running into the same issue. Will try Uvicorn when I get a chance to see if the issue carries over.

---

<div class="post-metadata">

**Author:** ![ZipBrandon](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/zipbrandon/32/13482_2.png) [@ZipBrandon](https://forum.djangoproject.com/u/ZipBrandon)\
**Post date:** [April 28, 2023, 2:25pm UTC](https://forum.djangoproject.com/t/operationalerror-sorry-too-many-clients-already/16221/28 "2023-04-28T14:25:08Z")

</div>

I’m facing this in development runserver while using Daphne with CONN\_MAX\_AGE = 0. It also exhibits the same condition of reaching too many clients when running Uvicorn.

In my application, I use Django to proxy most of my requests to a Node.js server using `httpx` in an async view. The node.js application receiving this proxied request executes graphql operations back to django.

I’m wondering if I have some lingering async connections that aren’t being closed properly. Most of my values in the `query` column in `pg_activity` are selecting a user from the Auth middleware.

EDIT: I swapped out my async view proxy with a sync view proxy and the connections are not building up. I’ll investigate further.

---

<div class="post-metadata">

**Author:** ![samul-1](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/samul-1/32/4767_2.png) [@samul-1](https://forum.djangoproject.com/u/samul-1)\
**Post date:** [May 20, 2023, 12:28pm UTC](https://forum.djangoproject.com/t/operationalerror-sorry-too-many-clients-already/16221/29 "2023-05-20T12:28:30Z")

</div>

I will have to add some Django Channels-based functionalities in my app, so I am once again faced with the issue of having to go back to an ASGI server.

Has anybody found a workaround for this issue? I was going to use uvicorn instead of daphne, but from @marty0678’s response I see that wouldn’t fix the issue.

I don’t understand how this hasn’t gotten more attention, as it seems to be a pretty big issue for anybody running ASGI.

---

<div class="post-metadata">

**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\
**Post date:** [May 20, 2023, 2:36pm UTC](https://forum.djangoproject.com/t/operationalerror-sorry-too-many-clients-already/16221/30 "2023-05-20T14:36:34Z")

</div>

Unfortunately, I’ve never seen this issue. Granted, I don’t typically see more than 25 - 30 concurrent connections at any one time, but my environments running my mix of uwsgi and daphne behind nginx has never had anything like this problem, and have been up continuously for months at a time.

---

<div class="post-metadata">

**Author:** ![alfonsrv](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/alfonsrv/32/15295_2.png) [@alfonsrv](https://forum.djangoproject.com/u/alfonsrv)\
**Post date:** [August 11, 2023, 3:22pm UTC](https://forum.djangoproject.com/t/operationalerror-sorry-too-many-clients-already/16221/31 "2023-08-11T15:22:06Z")

</div>

I’m also facing this issue. I originally thought it might have something to do with the dev environment exclusively, but it now also appeared in production. I had `CONN_MAX_AGE` set to `60` in production, but still see idle connections from 17h+ ago in the database, mostly regarding `COMMIT`.

I do not have `ATOMIC_REQUEST` set to `True` in dev, but do use it in prod. My prod environment only has like 5 users so far, 6 Daphne workers, 3 Celery workers. The 100 default Postgres connections should be enough! I deployed a lot of projects, but since using Channels and Daphne this is quite a terrifying outcome.

Other than that I’m also querying the user model, using the django-channels example of using websockets like this:

```auto
class FooConsumer(WebsocketConsumer):

    def connect(self):
        self.user = self.scope['user']
        ...

```

Has anyone been able to resolve this issue? Thanks.

---

<div class="post-metadata">

**Author:** ![MartinThoma](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/martinthoma/32/25090_2.png) [@MartinThoma](https://forum.djangoproject.com/u/MartinThoma)\
**Post date:** [November 10, 2024, 10:20am UTC](https://forum.djangoproject.com/t/operationalerror-sorry-too-many-clients-already/16221/32 "2024-11-10T10:20:00Z")

</div>

To people coming late to this topic:

As of Django 5.1 (released August 2024) connection pooling is directly supported: [Databases | Django documentation | Django](https://docs.djangoproject.com/en/5.1/ref/databases/#connection-pool) 🎉 I’ll give that a try now to see if my Heroku / Postgres connection issues get fixed.

---

<div class="post-metadata">

**Author:** ![MaulikPatel](https://avatars.discourse-cdn.com/v4/letter/m/848f3c/32.png) [@MaulikPatel](https://forum.djangoproject.com/u/MaulikPatel)\
**Post date:** [January 10, 2025, 11:30am UTC](https://forum.djangoproject.com/t/operationalerror-sorry-too-many-clients-already/16221/33 "2025-01-10T11:30:49Z")

</div>

Is the connection issue resolved now?

---

<div class="post-metadata">

**Author:** ![leandrodesouzadev](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/leandrodesouzadev/32/8981_2.png) [@leandrodesouzadev](https://forum.djangoproject.com/u/leandrodesouzadev)\
**Post date:** [January 10, 2025, 6:37pm UTC](https://forum.djangoproject.com/t/operationalerror-sorry-too-many-clients-already/16221/34 "2025-01-10T18:37:55Z")

</div>

Well, that’s not very specific. One can not use the new connection pool and still not have connection issues, and other can use the new connection pool and have this problem as well.  
I recently (just yesterday) had this problem, I had over 400 connections open to the database, with a spike in usage on one of our API endpoints and suddenly the Django process was really slow, and most of the requests were crashing due to no more connections available.  
We solved this problem using the new connection pool feature added, and it worked like a charm.  
For reference, this is the configuration that we’re now using:

```auto
# settings.py
DATABASES = {"default": env.db("DATABASE_URL")}
DATABASES["default"]["OPTIONS"] = {"pool": {"min_size": 2, "max_size": 10, "timeout": 10}}

```

You can learn more about the numbers you should put in for min/max size and timeout on the [psycopg3 connection pool documentation](https://www.psycopg.org/psycopg3/docs/advanced/pool.html#connection-pools) and on this [article](https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing) referenced there.

Since them we’ve not ran into any issues.

[Previous page](https://forum.djangoproject.com/t/operationalerror-sorry-too-many-clients-already/16221.md?page=1)