Kafka es rápido — yo usaré Postgres

• Se evaluó con benchmarks el rendimiento de publish/subscribe (pub-sub) y colas (queue) de Postgres, mostrando que incluso una sola base de datos puede potencialmente reemplazar un sistema de mensajería
• En un solo nodo de 4 vCPU logró 5,036 escrituras y 25,183 lecturas por segundo, y mantuvo un rendimiento similar incluso en un entorno replicado de 3 nodos, con una latencia de extremo a extremo de 186 ms (p99)
• En un nodo grande de 96 vCPU alcanzó 238 MiB/s de escritura y 1.16 GiB/s de lectura, confirmando capacidad de procesamiento holgada con un uso de CPU inferior al 10%
• En las pruebas de colas también pudo procesar 2,885 operaciones por segundo en un solo nodo y 2,397 en un entorno replicado, un rendimiento suficiente para la mayoría de las empresas
• Demuestra que, en lugar de sistemas distribuidos complejos, una sola infraestructura con Postgres puede manejar cargas de trabajo de varios MB/s, y enfatiza un enfoque práctico: “usa tecnología simple hasta que realmente necesites otra cosa”

---

Los dos bandos de la elección tecnológica

• La industria tecnológica se divide entre el bando guiado por palabras de moda y el bando guiado por el sentido común
  • El primero se siente atraído por términos de marketing como “tiempo real”, “escalado infinito” o “impulsado por IA”
  • El segundo prioriza la simplicidad y la practicidad, y evita la complejidad innecesaria
• Últimamente, dos corrientes han reforzado al segundo grupo: Small Data y el renacimiento de Postgres
  • Los datos se hacen más pequeños y el hardware se vuelve más potente
  • Postgres puede reemplazar varias soluciones especializadas con un solo sistema (jsonb, pgvector, tsvector, etc.)

Resumen del benchmark

• Objetivo: medir hasta qué punto Postgres puede escalar en mensajería pub/sub y procesamiento de colas
• Entorno de prueba: AWS EC2 c7i.xlarge (4 vCPU) y c7i.24xlarge (96 vCPU)
• Comparación entre tres configuraciones
  • Nodo único
  • Clúster replicado de 3 nodos
  • Nodo único de gran tamaño

Resultados del benchmark de pub/sub

• Nodo único de 4 vCPU
  • Escritura de 4.8 MiB/s (5,036 msg/s), lectura de 24.6 MiB/s (25,183 msg/s), latencia de 60 ms (p99)
  • Uso de CPU del 60%, escritura en disco de 46 MiB/s
• Replicación de 3 nodos con 4 vCPU
  • Escritura de 4.9 MiB/s, lectura de 24.5 MiB/s, latencia de 186 ms (p99)
  • Se mantiene el rendimiento, con un costo anual aproximado de $11,514
• Nodo único de 96 vCPU
  • Escritura de 238 MiB/s (243k msg/s), lectura de 1.16 GiB/s (1.2M msg/s), latencia de 853 ms (p99)
  • CPU por debajo del 10%; el cuello de botella está en la velocidad de escritura por partición
• Conclusión: puede competir con Kafka en cargas de trabajo pequeñas y medianas, y con una arquitectura simple puede procesar decenas de MB/s

Resultados del benchmark de colas

• Implementación de cola simple basada en SELECT FOR UPDATE SKIP LOCKED
• Nodo único de 4 vCPU
  • 2.81 MiB/s (2,885 msg/s), latencia de 17.7 ms (p99), CPU al 60%
• Replicación de 3 nodos con 4 vCPU
  • 2.34 MiB/s (2,397 msg/s), latencia de 920 ms (p99), CPU al 60%
• Nodo único de 96 vCPU
  • 19.7 MiB/s (20,144 msg/s), latencia de 930 ms (p99), CPU entre 40% y 60%
• Incluso un solo nodo puede cubrir las necesidades de rendimiento de colas de la mayoría de las empresas

Cuándo elegir Postgres

• En la mayoría de los casos, elegir Postgres por defecto es razonable
  • Permite depurar, modificar y hacer joins sobre mensajes con SQL
  • Frente a Kafka, simplifica la operación y facilita el mantenimiento
• Kafka está optimizado para alto rendimiento, pero para cargas pequeñas puede ser una elección excesiva
• Se cita la advertencia de Donald Knuth: “la optimización prematura es la raíz de todos los males”
  • Hasta varios MB/s, Postgres es suficiente

Enfoque de MVI

• Minimum Viable Infrastructure: construir el sistema mínimo con tecnologías que la organización ya conoce
  • Postgres está ampliamente adoptado y es fácil encontrar talento que lo maneje
  • Cuantos menos componentes haya, menor será la carga operativa y el riesgo de fallas
• Introducir tecnologías innecesarias genera sobrecarga organizacional
  • Aumentan los costos de aprendizaje, monitoreo, despliegue y operación

Debate sobre escalabilidad

• Postgres realmente puede escalar
  • OpenAI sigue usando Postgres basado en una sola instancia de escritura
  • Opera de forma estable incluso a escala de cientos de millones de usuarios
• La mayoría de las empresas crecen de forma gradual, así que hay margen de años antes de necesitar un cambio tecnológico
• Diseñar “por si se vuelve viral” es un sobrediseño excesivo
  • Se compara con “comprar un amplificador Marshall para abrirle a Coldplay”

Conclusión

• “Usa Postgres hasta que se rompa”
  • Incluso con tecnología simple se puede obtener un rendimiento bastante alto
  • Introducir sistemas distribuidos complejos antes de necesitarlos es ineficiente
  • Junto con el hardware moderno, Postgres es una opción práctica capaz de soportar la mayoría de las cargas de trabajo

[GN⁺]

Comentarios en Hacker News

• Aplicar el principio de Pareto a todo es una interpretación errónea
  Decir que Postgres cubre el 80% de los casos de uso de Kafka con el 20% del esfuerzo es una afirmación sin fundamento
  El principio de Pareto solo tiene sentido en situaciones donde aparece una distribución de ley de potencias
  Basta con decir que Postgres cubre suficientes casos de uso, es estable y es una herramienta probada

  • Pero también hay quien opina que el mapeo entre casos de uso y funcionalidades podría seguir por sí mismo una distribución de ley de potencias

• Por experiencia trabajando desde escalas pequeñas (cientos de eventos por hora) hasta grandes escalas (billones de eventos por hora), primero hay que preguntarse si de verdad hace falta una cola

  1. Tal vez baste simplemente con hacer polling a la base de datos
  2. Si una sola máquina lo puede manejar, se puede resolver con serverless o con un solo proceso
  3. Si no es un caso donde realmente haga falta una cola distribuida, balanceo de carga + API REST + reintentos asíncronos puede ser suficiente
  4. Si de verdad hace falta una cola distribuida, me parece mejor usar una solución dedicada como Kafka
  • Hay que dejar claro que Kafka en realidad no es una cola sino un sistema de logs distribuido. Mucha gente lo confunde como reemplazo de un MQ
  • En startups, a menudo los ingenieros tienden a elegir tecnologías complejas pensando más en su siguiente paso de carrera que en el proyecto actual
  • Si diseñas la estructura del código para soportar tanto una cola basada en PostgreSQL como una basada en Kafka, luego será más fácil cambiar
  • PostgreSQL tiende a volverse un cuello de botella cuando aumenta la carga de escritura. Los flujos de UPDATE son especialmente dolorosos
  • Como desarrollador Java, siempre necesité colas. El polling a la base de datos era un dolor de cabeza en entornos con múltiples consumidores y productores. Los consumer groups y partitions de Kafka ayudaron mucho con el manejo de estado

• Es riesgoso usar Postgres para todo
  Los locks y niveles de aislamiento no son intuitivos y pueden crear cuellos de botella de rendimiento
  Llevo décadas usando Postgres, pero no se debe diseñar con una fe ciega

  • Cuando el tráfico se dispara, el problema es el límite del escalado vertical. Kafka absorbe picos de tráfico, pero Postgres se sobrecarga con facilidad
  • Estaría bien que Postgres agregara una estructura de cola sostenible, pero es difícil escalar más allá del nivel de Redis y LISTEN/NOTIFY no escala (enlace relacionado)
  • En realidad, en cualquier almacén de datos hay que entender el modelo de concurrencia. Incluso entre bases de datos relacionales hay grandes diferencias
  • Postgres no puede escalar indefinidamente, pero con procesamiento por lotes y trabajo por fila individual puede manejar bastante volumen de datos
  • Personalmente, primero empiezo con Postgres y, si aparece un cuello de botella, entonces migro a otro sistema

• Me parece efectivo el enfoque de una tabla de log de eventos basada en SQL
  Pero la desventaja es la falta de herramientas del lado del cliente. Ahí Kafka tiene la ventaja de un ecosistema rico de librerías
  En nuestra empresa estandarizamos el envío de eventos entre servicios con una base SQL (feedapi-spec)
  No está tan maduro como Kafka, pero podría evolucionar hacia un stack común de librerías compatible con varios motores de almacenamiento

  • Con la mejora de las herramientas de generación de código basadas en LLM, se ha vuelto más fácil cerrar este vacío del lado del cliente
  • Para alguien a quien no le gusta Kafka, este enfoque resulta mucho más atractivo

• Últimamente la gente tiende a sentirse demasiado atraída por las tecnologías nuevas
  Postgres es excelente, pero hay que usar la herramienta adecuada para el problema
  Postgres no fue diseñado para pub-sub, Kafka sí fue creado para eso
  Hay que evitar la tendencia de productos que quieren “hacerlo todo”. Creo que son mejores las herramientas que hacen una sola cosa bien

• Implementar "números de offset monótonamente crecientes" es un problema complicado
  Una secuencia simple causa problemas porque el orden de la transacción y el momento del commit pueden no coincidir

  • Una forma es tener una tabla dedicada de contadores y garantizar el orden con locks dentro de la misma transacción (enlace de referencia)
  • También se puede garantizar el orden en entornos distribuidos usando Lamport Clock o Vector Clock (Lamport timestamp, Vector clock)
  • En vez de forzar un orden absoluto, es más realista asignar números por lotes o hacer que un proceso separado los asigne después del commit
  • También existe la forma de evitar procesamiento duplicado con SELECT FOR UPDATE SKIP LOCKED

• Queda la duda de si realmente hicieron benchmarks de Kafka
  Los resultados obtenidos en un entorno de 96 vCPU también se pueden lograr con una configuración de Kafka de 4 vCPU
  El rendimiento de Postgres es anormalmente lento
  Si no hace falta Kafka, no lo uses, pero presumir 5k msg/s con Postgres no significa gran cosa

  • Redpanda (implementación compatible con Kafka) maneja 250 mil mensajes por segundo incluso en una laptop (video)
  • Tener un rendimiento inferior a eso en un entorno de 288 vCPU es un desperdicio
  • Si la razón para usar Postgres es simplemente “ya lo tenemos”, se entiende, pero igual hace falta validar antes de agregar nueva infraestructura
  • Kafka llega al límite del ancho de banda de red incluso con poco hardware
  • Operarlo en AWS con una sola instancia 24xlarge es ineficiente; con ese costo se puede operar un gran clúster de Kafka

• Existen dos extremos: “la gente obsesionada con tecnologías nuevas” y “la gente que solo insiste en lo que ya aprendió”
  Un ingeniero realista toma una decisión práctica en algún punto intermedio

  • Yo soy de un tercer tipo: de los que piensan “todo lo que hay ahora está más o menos mal, y lo nuevo seguramente también lo estará”
  • Al final, lo importante es mirar el problema con criterio y encontrar la mejor solución
  • Por ejemplo, intentar reemplazar Elasticsearch con Postgres puede ser posible, pero en calidad de búsqueda ES es muy superior

• La funcionalidad clave de Kafka es el control de offsets por consumidor
  En entornos donde varios equipos leen el mismo tópico, es una función indispensable
  Poder mover el offset hacia adelante o hacia atrás me ha salvado más de una vez
  Me pregunto si una cola en Postgres soporta ese tipo de función

  • También hay quien opina que cada consumidor podría gestionar su propio offset
  • Pero en la mayoría de los casos, si no se necesita alto throughput, tampoco hace falta toda la complejidad del manejo de offsets de Kafka
  • Al final es una cuestión de equilibrio entre la velocidad que exige el negocio y la complejidad operativa

• La idea de “el bando que persigue buzzwords vs. el bando del sentido común” en sí misma está equivocada
  Reimplementar Kafka con Postgres no es sentido común
  Si de verdad necesitas funcionalidades al nivel de Kafka, entonces simplemente usa Kafka

  • En realidad, no implementaron Kafka completo, sino solo dos consultas simples de pub-sub