PostgreSQL connection leak: idle connections accumulate and exhaust max_connections (0.7.2)

[guipratiko]

Welcome!

• Yes, I have searched for similar issues on GitHub and found none.

What did you do?

Running Evolution GO 0.7.2 with PostgreSQL 17 (Docker) and a small number of WhatsApp instances (4–5 created, ~4 connected at the same time).

Setup:

• PostgreSQL 17.10 (Debian, Docker container)
• Default max_connections = 100
• Evolution GO connected to database evogo_auth (whatsmeow tables)
• Multiple instances active, handling normal message traffic

Steps:

1. Deploy Evolution GO 0.7.2 and connect 4 WhatsApp instances
2. Let the service run under normal load (messages, contacts, webhooks)
3. Monitor PostgreSQL with pg_stat_activity
4. Optionally delete/disconnect instances and observe connection count

Monitoring queries used:

SELECT count(*) FILTER (WHERE client_addr = '<evolution_go_ip>') AS evolution_go,
       count(*) AS total
FROM pg_stat_activity;

SELECT pid, datname, client_addr, state, LEFT(query, 100)
FROM pg_stat_activity
WHERE client_addr = '<evolution_go_ip>';

### What did you expect?

- Evolution GO should maintain a **reasonable, bounded connection pool** per instance
- Idle connections should be **released** when instances are deleted/disconnected
- Total DB connections should scale roughly linearly with active instances (e.g. ~2–4 per instance), not grow unbounded
- The service should **not** exhaust PostgreSQL `max_connections` with only a handful of instances
What did you ob

### What did you observe instead of what you expected?

With only **4 connected instances**, Evolution GO opened **12–16+ idle connections** to PostgreSQL (`evogo_auth`), all from the same container IP. Over time, connections kept increasing even after deleting most instances.

Eventually PostgreSQL logged: FATAL: sorry, too many clients already


When the limit was hit, Evolution GO entered a **retry loop** (~every 2 seconds), making the situation worse. Instances became unstable and required restarting both PostgreSQL and Evolution GO.

**Example `pg_stat_activity` (healthy-looking period before crash):**
- `evolution_go`: 16 connections
- `total`: 24 / 100
- Most connections: `state = idle`
- Last queries included:
  - `INSERT INTO whatsmeow_message_secrets (...)`
  - `SELECT first_name, full_name, push_name, business_name, redacted_phone FROM ...`
  - `SELECT version, compat FROM whatsmeow_version LIMIT 1`

**After deleting instances:** connection count did **not** drop proportionally — suggesting a **connection leak**.

**Workaround:** Downgrading to **0.7.1** on the same infrastructure:
- Only **3 idle connections** total (2 → `auth`, 1 → `users`)
- New container IP, databases split as `onlydbevoflow_auth` + `onlydbevoflow_users`
- No `too many clients` errors under the same workload

This suggests a **regression in 0.7.2** around DB connection lifecycle / pool management.

### Screenshots/Videos

_No response_

### Which version are you using?

0.7.2 (issue); workaround verified on 0.7.1


### What is your environment?

Docker

### If applicable, paste the log output

**PostgreSQL — connection limit reached:**
2026-07-10 12:37:15.989 UTC [277] FATAL: sorry, too many clients already 2026-07-10 12:37:42.693 UTC [280] FATAL: sorry, too many clients already ... 2026-07-10 15:17:28.880 UTC [985] FATAL: sorry, too many clients already 2026-07-10 15:18:41.730 UTC [1030] FATAL: sorry, too many clients already (retry storm: dozens of FATAL errors every ~2 seconds between 15:17–15:20 UTC)

**PostgreSQL — startup (normal):**
PostgreSQL Database directory appears to contain a database; Skipping initialization LOG: database system is ready to accept connections

**Heavy checkpoint activity before/during incident (possible symptom of high write load):**
checkpoint complete: wrote 3166 buffers (19.3%); write=269.127 s; distance=33948 kB checkpoint complete: wrote 3865 buffers (23.6%); write=269.907 s; distance=38841 kB

**Connection stats (0.7.2, before crash):**
evolution_go | total | limite 16 | 25 | 100

**Connection stats (0.7.1, same workload after downgrade):**
datname | client_addr | state | qtd onlydbevoflow_auth | 10.11.63.135 | idle | 2 onlydbevoflow_users | 10.11.63.135 | idle | 1

### Additional Notes

**Suspected root cause:** Connection pool not releasing idle connections on instance disconnect/delete; possible leak per instance or per goroutine in 0.7.2.

**Impact:** Production outage — all DB clients rejected once `max_connections` is hit; Evolution GO retry loop accelerates exhaustion.

**Suggested investigation:**
- Compare `database/sql` pool settings (`SetMaxOpenConns`, `SetMaxIdleConns`, `SetConnMaxLifetime`) between 0.7.1 and 0.7.2
- Ensure `Close()` / pool cleanup runs on instance delete and disconnect
- Add connection pool metrics or logging for observability

**Mitigations we applied:**
- Increased `max_connections` to 1000
- Downgraded to 0.7.1 (resolved the issue)
- `idle_session_timeout` on PostgreSQL (preventive)

Happy to provide more logs or test a patched 0.7.2 build.

[guilhermeCassettari]

This should be fixed by #117 — it makes the whatsmeow auth-store use a single shared sqlstore.Container with a capped pool instead of opening a new unbounded one on every (re)connect. Reproduced the leak locally (15 reconnects: 1 → 16 connections, unbounded growth afterwards) and verified the fix keeps it at 1-2.

[guipratiko]

This should be fixed by #117 — it makes the whatsmeow auth-store use a single shared sqlstore.Container with a capped pool instead of opening a new unbounded one on every (re)connect. Reproduced the leak locally (15 reconnects: 1 → 16 connections, unbounded growth afterwards) and verified the fix keeps it at 1-2.

Thanks for the update! I actually fixed this on my own in version 0.7.2 by reusing a shared SQL store instead of creating a new one on every reconnect. After applying that change, the connection growth issue was resolved in my environment. Good to see that #117 addresses the same root cause.

[sistemabritto]

Investigated this against our own setup (also hit too many clients already on a shared Postgres, same idle-connection-accumulation pattern, ~260 idle connections from a single instance reconnect).

Found a concrete leak, present identically in both 0.7.1 and 0.7.2 (diffed pkg/whatsmeow/service/whatsmeow.go::StartClient between the two tags — this specific function is byte-identical), so it isn't the whole story behind the reported regression, but it's a real, reproducible leak worth fixing on its own:

var container *sqlstore.Container
// ...
container, err = sqlstore.New(context.Background(), "postgres", w.config.PostgresAuthDB, nil)
// ...
w.clientPointer[cd.Instance.Id] = client

Every call to StartClient — i.e. every reconnect, not just the first connect — creates a brand new sqlstore.Container (a brand new underlying *sql.DB connection pool) via sqlstore.New(...). Only the whatsmeow client gets tracked in w.clientPointer[cd.Instance.Id]; the container variable is local to the function, never stored anywhere, never closed, never reused. Each reconnect leaks one full connection pool's worth of Postgres connections that only go away when Postgres itself times them out or the process restarts.

This matches the "doesn't drop proportionally on disconnect" symptom: the idle count correlates with how many times StartClient has ever run for an instance, not with how many instances are currently connected.

Since the function is identical across 0.7.1/0.7.2, the version-to-version difference you saw is likely in how often StartClient gets triggered (something upstream of it), not in this function itself — worth checking if 0.7.2 reconnects more aggressively. Either way, this leak itself is worth fixing regardless of that: track the container per instance (same map pattern as clientPointer) and reuse the existing one on reconnect, or explicitly container.Close() the previous one before creating a new one.

Happy to open a PR for this specific fix if useful.

[ShowtimeProp]

I've got 500 connections exhausted within 94 minutes with 7 instances , that's crazy So I will try to implement idle_session_timeout in the yml

evolution_go_postgres:
image: postgres:15-alpine
command: ["postgres", "-c", "max_connections=500", "-c", "shared_buffers=256MB", "-c", "idle_session_timeout=600000"]

And I'll let you know tomorrow how it goes!

OK here are the results: "the trigger in our case turned out to be unpaired instances looping on QR — details in #106".

This is the YML that finally worked out!

services:
evolution_go:
image: evoapicloud/evolution-go:0.7.2
environment:
CONNECT_ON_STARTUP: "false" # was "true" — that was the trigger
QRCODE_MAX_COUNT: "5"
DATABASE_SAVE_MESSAGES: "false"
# both DSNs point to the same database
POSTGRES_AUTH_DB: "postgresql://USER:PASS@postgres:5432/evogo?sslmode=disable"
POSTGRES_USERS_DB: "postgresql://USER:PASS@postgres:5432/evogo?sslmode=disable"

postgres:
image: postgres:15-alpine
command: ["postgres", "-c", "max_connections=500", "-c", "shared_buffers=256MB", "-c", "idle_session_timeout=600000"]

---

Note:
One more data point: we point POSTGRES_AUTH_DB and POSTGRES_USERS_DB at the
same database. Given the issue title mentions evogo_auth/evogo_users, if a
separate pool is opened per DSN, each leaked client may be leaking two pools
rather than one. Might be worth checking whether the two stores share a pool
when both DSNs resolve to the same database.

-> versión of whatsmeow, the one that brings 0.7.2 from factory, no override.

------------------------ The YML Above wasn't sufficient so I had to Install PGbouncer ----------------------

Update: setting CONNECT_ON_STARTUP=false was not sufficient on its own.
Connection exhaustion returned ~54 minutes later, with the same logged-out
instances in the logs — so something other than startup is triggering connects
on unpaired instances. We ended up putting PgBouncer in transaction mode in
front of Postgres, which makes the leak harmless: GO currently holds 29 client
connections while PgBouncer keeps 0 server connections open.