PostgreSQL puede reemplazar a Redis y Kafka — y nadie te lo dijo

Si eres desarrollador, probablemente has escuchado la misma cantaleta: "PostgreSQL LISTEN/NOTIFY no escala. Usa Redis. Usa Kafka. Usa algo que no sea Postgres para pub/sub."

Pues resulta que todo ese tiempo estuviste desperdiciando dinero en servicios externos que no necesitabas.

Un equipo de DBOS (sí, los fundada por el legendario Mike Stonebraker, el mismo que inventó Ingres y Postgres original) acaba de publicar un estudio demoledor: PostgreSQL puede manejar 60,000 escrituras por segundo en un solo servidor con latencia de milisegundos usando LISTEN/NOTIFY. La clave no fue cambiar Postgres — fue entender cómo optimizarlo.

El mito que todos repetimos

En 2023, un blog post viral aseguró que LISTEN/NOTIFY no escala. Mostraba un cuello de botella misterioso: la base de datos se saturaba sin consumir CPU, memoria ni IOPS visibles. Como si hubiera un fantasma dentro del motor.

La comunidad lo aceptó como verdad revelada. "Para pub/usb, usa Redis", "Para streams, usa Kafka", "Postgres es solo para datos transaccionales". Y así nacieron arquitecturas hinchadas con 3, 4 o 5 servicios diferentes solo para notificaciones en tiempo real.

¿El problema real? PostgreSQL tiene un lock global exclusivo durante la operación NOTIFY. Cada transacción que llama a NOTIFY debe esperar su turno para adquirir ese lock antes de committear. A alto volumen, eso forma una fila invisible que estrangula el rendimiento.

60K writes/segundo: cómo lo lograron

El equipo de DBOS no reinventó Postgres. Hicieron algo mucho más simple: dejaron de hacer NOTIFY por cada fila insertada.

En lugar de disparar una notificación por cada chunk de stream (con un trigger que llamaba a NOTIFY por cada INSERT), acumularon múltiples escrituras y enviaron una sola notificación por lote. El trigger se reemplazó por una función que verifica si hay datos nuevos cada cierto umbral, y solo entonces llama a NOTIFY.

El resultado: pasaron de 2,900 writes/segundo a 60,000 writes/segundo — un incremento de 20x. En un solo servidor PostgreSQL. Sin cambiar hardware. Sin añadir Redis. Sin Kafka.

¿Qué significa esto para tu stack?

Que probablemente estás pagando por servicios que no necesitas.

Para la mayoría de aplicaciones — chats en vivo, feeds de actividad, notificaciones push, streaming de LLM token por token, dashboards en tiempo real — PostgreSQL con LISTEN/NOTIFY optimizado es más que suficiente. Y te ahorras:

• 💸 El costo de mantener Redis (memoria RAM, clusters, failover)
• 💸 La complejidad operativa de Kafka (ZooKeeper, particionamiento, offsets)
• 💸 La latencia de red entre servicios
• 💸 El riesgo de inconsistencia entre tu base de datos y tu caché

Un solo Postgres bien configurado = una docena de microservicios que no necesitas.

La ironía: LISTEN/NOTIFY existe desde 1996

Esta funcionalidad lleva en PostgreSQL casi 30 años. Desde la versión 6.3, lanzada en 1998, cualquier desarrollador podía escribir:

-- Cliente 1: Escucha
LISTEN canal_notificaciones;

-- Cliente 2: Notifica
NOTIFY canal_notificaciones, 'nuevo mensaje';

Y sin embargo, muy pocos lo usaban porque "no escala". Resulta que el problema no era la feature, era cómo la estábamos usando.

La lección aquí va más allá de PostgreSQL: cuando algo "no funciona" en producción, pregúntate si el problema es la herramienta o tu implementación. Muchas veces, una optimización quirúrgica — no un reemplazo total — es lo que realmente necesitas.

¿Cuándo SÍ necesitas Redis o Kafka?

No todo es fanatismo. LISTEN/NOTIFY tiene limitaciones reales:

• 🔴 No persiste mensajes históricos (si el lector se desconecta, pierde las notificaciones)
• 🔴 No tiene particionamiento nativo (un solo canal, un solo lock)
• 🔴 No escala horizontalmente tan bien como Kafka para >100K writes/segundo
• 🔴 Los subscribers deben mantener conexión persistente a la base de datos

Para sistemas que necesitan reprocesamiento de eventos, almacenamiento duradero de streams, o escalar a cientos de miles de writes/segundo, Kafka sigue siendo la opción correcta. Para caché de alta velocidad con expiración automática, Redis sigue ganando.

Pero para el 80% de los casos de uso de pub/sub en aplicaciones web — chats, notificaciones, eventos en vivo — PostgreSQL con LISTEN/NOTIFY optimizado es todo lo que necesitas.

El veredicto

DBOS acaba de demostrar lo que muchos sospechábamos: PostgreSQL es mucho más capaz de lo que le damos crédito. El mito de que "LISTEN/NOTIFY no escala" está oficialmente muerto. Con 60K writes/segundo y latencia de milisegundos, es una alternativa legítima a Redis y Kafka para decenas de casos de uso.

Así que la próxima vez que alguien te diga "necesitamos Redis para pub/sub", pregúntale: ¿ya optimizaste PostgreSQL primero?

Comparte esto con ese amigo que todavía cree que necesita Kafka para su app de 500 usuarios.