Connection pooling and a read path that scales #29

New Issue

2026-09-01T23:27:47Z

paulhitt commented

2026-09-01 23:27:47 +00:00

(Migrated from gitlab.com)

Postgres max_connections = 100 is the real ceiling, and every held long-poll draws from it. PgBouncer in front is the cheapest large win and needs no protocol change; a read replica for the cursor query is the next step.

Trade: almost none for PgBouncer. A replica adds replication lag to a path where "did my message arrive" is the question being asked.

⚠️ Idea, not a commitment. Filed 2026-09-01 during the code freeze — design and cost it, do not build it yet.

Postgres `max_connections = 100` is the real ceiling, and every held long-poll draws from it. PgBouncer in front is the cheapest large win and needs no protocol change; a read replica for the cursor query is the next step. **Trade:** almost none for PgBouncer. A replica adds replication lag to a path where "did my message arrive" is the question being asked. --- ⚠️ Idea, not a commitment. Filed 2026-09-01 during the code freeze — design and cost it, do not build it yet.

paulhitt commented

2026-09-04 21:26:47 +00:00

(Migrated from gitlab.com)

Built and merged; deployed 2026-09-04. The read-path half is written up in docs/POOLING.md — and note the premise correction recorded there: held polls do NOT pin a connection, which is what the original issue assumed. Three steps are still owed before PgBouncer goes to production, listed in that file.

Built and merged; deployed 2026-09-04. The read-path half is written up in `docs/POOLING.md` — and note the premise correction recorded there: held polls do NOT pin a connection, which is what the original issue assumed. Three steps are still owed before PgBouncer goes to production, listed in that file.

paulhitt (Migrated from gitlab.com) closed this issue

2026-09-04 21:26:47 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: extant2000/flamenet-relay#29