DBOS escala Postgres LISTEN/NOTIFY a 60K QPS: guía 2026

El problema que nadie te contó sobre Postgres LISTEN/NOTIFY

60.000 escrituras por segundo es lo que logró DBOS optimizando Postgres LISTEN/NOTIFY, pasando de un cuello de botella de apenas 2.900 QPS. La diferencia: buffering y batching de notificaciones que eliminan el bloqueo global que serializa transacciones.

Si tu startup usa Postgres para notificaciones en tiempo real, este dato cambia todo: no necesitas migrar a Redis o Kafka si optimizas correctamente. Pero hay un detalle crítico que la mayoría de los equipos descubre en producción, no en desarrollo.

¿Por qué LISTEN/NOTIFY se rompe bajo carga?

El problema está documentado desde julio de 2025, cuando Recall.ai identificó que su instancia de PostgreSQL se veía "bogged down" por escrituras concurrentes. La causa raíz: cuando emites un NOTIFY dentro de una transacción, Postgres adquiere un lock global sobre toda la instancia durante la fase de commit.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Esto significa que todos los commits se serializan. No es un bloqueo de fila ni de tabla: es un bloqueo a nivel de instancia que afecta a todas las bases de datos en ese servidor PostgreSQL. El síntoma es claro: latencia que se dispara y throughput que colapsa conforme aumentan los escritores concurrentes.

Simon Willison resumió el hallazgo señalando que este comportamiento está en el código fuente de PostgreSQL, pero no está documentado en la página oficial de LISTEN/NOTIFY. Es uno de esos detalles que solo descubres cuando tu aplicación ya está en producción y los usuarios se quejan de lentitud.

Los datos de la comunidad técnica son contundentes: LISTEN/NOTIFY escala linealmente con listeners inactivos, agregando aproximadamente 13 microsegundos extra por conexión. Con 1.000 listeners inactivos, un round-trip de NOTIFY pasa de ~0.4 ms a ~14 ms. Por encima de 5.000 notificaciones por segundo, entras en zona de riesgo de contención severa.

Cómo DBOS logró escalar a 60K QPS

El equipo de DBOS no abandonó LISTEN/NOTIFY. En su lugar, implementó una arquitectura de buffering y batching que transforma el patrón de uso. En lugar de emitir una notificación por cada evento, acumulan múltiples eventos y los notifican en lotes.

La clave técnica está en separar la persistencia del evento de la notificación. Los eventos se escriben en una tabla (puede ser una tabla no logueada para mayor velocidad), y un proceso separado agrupa múltiples eventos antes de emitir un único NOTIFY. Esto reduce drásticamente la frecuencia de locks globales durante commits.

El benchmark público de DBOS muestra la evolución: de 2.900 escrituras por segundo con el patrón naïve (un NOTIFY por transacción) a 60.000 escrituras por segundo con buffering y batching. La latencia se mantiene baja porque los workers reciben señales menos frecuentes pero con más trabajo por procesar.

El código del benchmark está disponible en GitHub, lo que permite replicar las pruebas en tu propio entorno. Esto es crítico: cada carga de trabajo es distinta, y lo que funciona para DBOS puede necesitar ajustes para tu caso específico.

¿Cuándo usar LISTEN/NOTIFY y cuándo evitarlo?

La guía práctica de NerdLevelTech para 2026 establece un principio claro: usa LISTEN/NOTIFY solo como señal de wake-up, nunca como la cola de trabajos en sí misma. Las notificaciones no son persistentes, tienen un payload máximo de 8.000 bytes, y NOTIFY serializa commits bajo carga.

Casos de uso recomendados para LISTEN/NOTIFY:

Indicadores de presencia en tiempo real (usuarios online/offline)
Invalidación de caché después de actualizaciones
Notificaciones de "nuevo comentario" en dashboards
Señales de trabajos lentos finalizados
Actualizaciones en paneles administrativos de baja frecuencia

Casos donde debes evitar LISTEN/NOTIFY:

Pipelines de eventos de alto volumen (>5.000 eventos/segundo)
Sistemas que requieren durabilidad de mensajes (si el consumidor cae, no puedes recuperar el mensaje)
Escenarios con muchos escritores concurrentes (>50 transacciones/segundo con NOTIFY)
Aplicaciones que necesitan replay de eventos históricos

El patrón production-safe para 2026 combina LISTEN/NOTIFY como señal de wake-up con una tabla de jobs que se consume usando SELECT ... FOR UPDATE SKIP LOCKED. Esto permite múltiples workers procesando en paralelo sin bloquearse entre sí, manteniendo las garantías transaccionales de PostgreSQL.

Alternativas: Redis, Kafka, SQS vs Postgres

Opción	Throughput	Durabilidad	Complejidad	Mejor para
Postgres LISTEN/NOTIFY	Medio (hasta 60K con optimización)	No persistente	Baja	Señales transaccionales ligeras
Redis Pub/Sub	Alto (100K+)	No persistente	Media	Fanout en tiempo real
Kafka	Muy alto (millones)	Persistente	Alta	Pipelines de eventos, replay
SQS	Alto	Persistente	Baja	Colas desacopladas, reintentos
Job table + SKIP LOCKED	Alto	Persistente	Media	Workflows transaccionales

La decisión no es binaria. Muchas startups exitosas usan combinaciones: Postgres para eventos transaccionales críticos, Redis para notificaciones en tiempo real a usuarios, y Kafka para pipelines de datos que requieren replay histórico.

Recall.ai tomó la decisión de migrar away de LISTEN/NOTIFY para disparar acciones sobre cambios en filas, reportando un boost significativo de rendimiento. Pero DBOS demuestra que con la arquitectura correcta, puedes mantener LISTEN/NOTIFY incluso bajo cargas intensas.

Qué significa esto para tu startup

Si estás construyendo un backend en 2026 y consideras LISTEN/NOTIFY para notificaciones en tiempo real, aquí tienes el análisis práctico:

No abandones PostgreSQL prematuramente. El movimiento automático hacia Redis o Kafka añade complejidad operativa que muchas startups early-stage no necesitan. DBOS demuestra que puedes lograr 60K QPS manteniendo todo en Postgres con las optimizaciones correctas.

Pero valida tu patrón antes de production. El problema del lock global no se manifiesta en desarrollo con pocos usuarios. Necesitas pruebas de carga que simulen tu escenario real de escrituras concurrentes. El benchmark de DBOS en GitHub es un punto de partida excelente.

Acciones concretas para implementar esta semana:

Audita tu uso actual de LISTEN/NOTIFY: Revisa tu código y cuenta cuántos NOTIFY emites por transacción. Si es más de uno por operación de usuario, probablemente estás en riesgo. Implementa buffering acumulando eventos en una tabla temporal y emitiendo un solo NOTIFY cada 100ms o cada 50 eventos.
Migra a job table + SKIP LOCKED para workloads pesados: Si procesas colas de trabajos, usa SELECT ... FROM jobs WHERE status = 'pending' FOR UPDATE SKIP LOCKED LIMIT 10. Esto permite múltiples workers sin contención. Usa LISTEN/NOTIFY solo para despertar workers inactivos, no para pasar el trabajo completo.
Establece límites de tasa desde el inicio: Implementa throttling a nivel de aplicación para limitar notificaciones a <5.000/segundo por instancia. Si superas ese umbral, escala horizontalmente añadiendo más instancias de base de datos en lugar de optimizar una sola.
Monitorea latencia de commit, no solo QPS: El síntoma del lock global es latencia de commit que se dispara bajo carga. Configura alertas cuando el percentil 95 de latencia de commit supere 50ms. Esto te dará señal temprana antes de que los usuarios noten problemas.

Conclusión

Postgres LISTEN/NOTIFY no está roto: solo requiere entender sus límites y aplicar patrones arquitectónicos probados. DBOS demostró que puedes escalar a 60.000 escrituras por segundo con buffering y batching, pero esto requiere diseño intencional, no el patrón naïve de un NOTIFY por transacción.

Para founders hispanohablantes construyendo en 2026, la lección es clara: no sigas tendencias ciegamente hacia microservicios y brokers externos si PostgreSQL bien configurado puede manejar tu carga. Pero tampoco ignores las señales de contención hasta que sea tarde.

La arquitectura correcta depende de tu volumen real, no de tu volumen proyectado. Prueba con carga real, mide latencia de commit, y optimiza solo cuando los datos lo justifiquen.