Postgres LISTEN/NOTIFY arrastra fama de no escalar, pero el cuello de botella —un cerrojo global durante el commit— es evitable. DBOS explica en este artículo técnico cómo construyó streams de baja latencia sobre Postgres usando notificaciones para evitar polling, qué problema apareció al escalar (un máximo de 2.900 escrituras por segundo) y por qué el parche previsto para Postgres 19 no resuelve esa limitación concreta.
La solución propuesta se basa en una observación clave: en un stream las notificaciones no son la fuente de verdad, solo avisan al lector para que consulte la tabla. Por ello se pueden acumular en un buffer en memoria y vaciarse en una única transacción por lotes, lo que reduce la contención del cerrojo global y permite aprovechar el group commit de Postgres. Como red de seguridad ante un crash que pierda notificaciones encoladas, los lectores aplican un polling periódico de baja frecuencia.
Con esta arquitectura, DBOS alcanza 60.000 escrituras de stream por segundo —20 veces más que la implementación inicial— manteniendo latencias de 15 a 100 ms, y con la CPU de Postgres totalmente utilizada en lugar de serializada por el cerrojo. El código de los benchmarks está disponible en el repositorio público de DBOS.