July 8, 2026
Pooling tea just got spicy
Multigres Supports Listen/Notify Across Pooled Connections
Postgres fans are split as Multigres pulls off a pooling magic trick listeners begged for
TLDR: Multigres says it found a way to keep Postgres alerts working even when apps don't hold a permanent server connection, which matters for busy systems that need fast updates. Commenters are split between calling it a brilliant fix and bracing for edge-case chaos.
Database nerds are having a surprisingly juicy moment over Multigres, after it claimed it can keep Postgres's built-in alert system working even when users don't stay attached to one server connection. In plain English: apps use this feature to shout "something changed!" without constantly checking, but it normally depends on one user sticking to one line. Multigres says it found a workaround, and the comments instantly turned into a mix of applause, suspicion, and meme posting.
The loudest reaction is basically "finally, someone fixed the annoying part" versus "cool trick, but what could possibly go wrong?" Fans called it a clever answer to a real pain point, especially for apps with lots of always-on listeners. Skeptics, meanwhile, were laser-focused on edge cases, warning that these systems always look elegant until one weird failure at 3 a.m. sends everyone into a spiral. A few commenters were impressed that Multigres tried to make it behave exactly like regular Postgres instead of shipping a "close enough" version, which in database land is practically a love letter.
And yes, the jokes arrived right on schedule. People compared the setup to a shared apartment mailbox for server alerts, while others joked that engineers will do literally anything to avoid polling. The overall vibe? Half the crowd is cheering a neat engineering flex, and the other half is standing in the back with folded arms asking, "show us the disasters you haven't mentioned yet."
Key Points
- •The article explains that PostgreSQL `LISTEN` registration is per session, while `NOTIFY` delivery is per database.
- •PostgreSQL sends notifications asynchronously as `NotificationResponse` messages outside the normal request/response flow.
- •In a pooled architecture like Multigres, clients do not own persistent backend sessions, so a naive `LISTEN` on a borrowed connection would strand the registration.
- •Notifications in a pooler could arrive on backend connections that have already been returned to the pool and reused by another client.
- •The article says Multigres solves this by using a single long-lived shared listener connection managed by the pooler rather than pinning each listening client to a dedicated backend.