Hablar de streaming de eventos en 2025 ya no es hablar solo de Apache Kafka. Redpanda se posiciona desde hace años como alternativa compatible con el protocolo Kafka pero construida sobre una base distinta, y en los últimos meses hay suficientes casos de producción como para tomarla en serio. El atractivo no está en ofrecer algo radicalmente nuevo, sino en mantener el protocolo al que ya está enganchada media industria y cambiar todo lo que hay debajo.

Puntos clave

  • Redpanda es un motor de streaming en C++ que reproduce el protocolo Kafka tal y como viaja por la red: las aplicaciones, librerías y conectores existentes funcionan sin cambios.

  • La arquitectura thread-per-core con Seastar elimina el GC de JVM, reduce la tail latency y hace el uso de CPU más predecible.

  • Sin ZooKeeper, sin JVM, sin Kafka Connect separado: son tres piezas menos que operar.

  • La compatibilidad con Kafka es alta para cargas estándar; funcionalidades recientes de Kafka Streams o el Schema Registry pueden requerir pruebas específicas.

  • Tiene sentido para equipos que parten de cero o donde la operación de Kafka ha sido un dolor recurrente. Para clusters Kafka estables con equipo experimentado, el cambio rara vez se justifica.

Qué es Redpanda y por qué existe

Redpanda es un motor de streaming escrito en C++ que reproduce el protocolo Kafka tal y como viaja por la red. Esto significa que las aplicaciones existentes, las librerías cliente y los conectores de Kafka funcionan sin cambios. Desde el punto de vista del desarrollador es Kafka; desde el punto de vista del operador es otra cosa.

La decisión de mantener el protocolo y cambiar la implementación responde a una realidad incómoda: el ecosistema Kafka es gigantesco, pero la operación del propio Apache Kafka es más dolorosa de lo que debería. ZooKeeper como dependencia separada, el tuning de JVM, el rebalanceo de particiones, las pausas de GC que rompen la latencia. El proyecto Kafka lleva años moviéndose hacia KRaft[1] para eliminar ZooKeeper, un modo estable desde la versión 3.3 y el único soportado desde la 4.0, pero el resto de problemas sigue ahí. Redpanda se plantea eliminarlos de raíz.

La arquitectura thread-per-core

El punto más diferencial de Redpanda es su motor basado en Seastar[2], el mismo entorno que usa ScyllaDB, tal y como detalla la documentación de arquitectura de Redpanda[3]. Seastar sigue el modelo thread-per-core: cada hilo está fijado a un núcleo físico y tiene su propia cola de trabajo, sin locks compartidos entre hilos. La comunicación entre núcleos se hace por paso de mensajes, no por memoria compartida con candados.

Las implicaciones concretas de rendimiento son tres:

  • La tail latency baja porque desaparecen las pausas de recolección de basura.

  • El uso de CPU es más predecible porque no hay planificación agresiva entre hilos.

  • Red y disco se manejan con E/S asíncrona directa sobre el kernel Linux, sin las capas de abstracción del JVM.

La contrapartida es que Redpanda es más sensible al hardware subyacente. En máquinas pequeñas o virtualizadas con CPU compartida, el modelo thread-per-core no luce tanto. En máquinas dedicadas, la diferencia con Kafka crece con el número de núcleos y con discos NVMe rápidos.

En sus propios benchmarks, Redpanda reporta hasta diez veces mejor latencia en el percentil 99,99 en cargas mixtas (comparativa publicada por Redpanda[4]). Un análisis independiente sobre cargas similares (Jack Vanlightly[5]) matiza la foto. Redpanda gana con claridad en acks=1 sobre mensajes pequeños, pero con acks=all Kafka igualó o superó el p99 de Redpanda en parte de las pruebas. Tras más de doce horas de carga sostenida, Redpanda mostró degradación de latencia.

Conviene medir en el propio entorno y con la configuración real de acks, no solo con los números de marketing.

Sin ZooKeeper, sin JVM, sin Connect separado

Redpanda elimina las dependencias que Kafka arrastra:

  • Sin ZooKeeper: el consenso está integrado en el propio broker mediante Raft, igual que KRaft en Kafka moderno.

  • Sin JVM: es un binario nativo compilado. Según los tamaños publicados en Docker Hub[6], la imagen oficial de Redpanda pesa unos 113 MB. La imagen oficial de Apache Kafka ocupa 260-370 MB, y bastante más en distribuciones que empaquetan la JVM completa, como Confluent Platform.

  • Sin Kafka Connect separado: existe un componente interno llamado Redpanda Connect basado en Benthos.

Desplegar Redpanda significa copiar un binario y arrancarlo. La configuración inicial cabe en un fichero YAML corto. Esto no es magia: las funcionalidades complejas siguen existiendo, solo están mejor integradas. Para equipos sin experiencia operando JVM en producción, eliminar el tuning de GC y las pausas stop-the-world es un alivio real.

Compatibilidad real con Kafka

La pregunta más importante al evaluar Redpanda es hasta qué punto es realmente compatible con Kafka. La respuesta corta: para las cargas estándar de publicación y consumo, sí.

El protocolo está implementado al nivel necesario para que los clientes oficiales de Java, Python, Go, Rust y otros funcionen sin cambios. Los conectores de Debezium para captura de cambios funcionan. Las librerías de alto nivel como kafka-streams también funcionan, aunque con algunas limitaciones en funcionalidades recientes.

Donde hay que tener cuidado es en funcionalidades específicas que llegan primero a Apache Kafka y después a Redpanda. Algunas transacciones idempotentes, características recientes de Kafka Streams y el propio Schema Registry tienen su propia implementación en Redpanda, compatible pero no idéntica. Para cargas estándar de publicación y consumo esto no importa; para arquitecturas que exprimen las funcionalidades al límite hay que hacer pruebas específicas.

El análisis de bases de datos para arquitecturas de streaming conecta con los patrones que describimos en Kafka para streaming de eventos. La estrategia de LLM routing que aparece en LLM routing multi-modelo muestra cómo el mismo patrón de selección se aplica a diferentes capas del stack.

Cuándo compensa y cuándo no

Redpanda compensa cuando:

  • La operación de Kafka ha sido un problema recurrente.

  • El equipo no tiene experiencia acumulada en JVM.

  • Se parte de cero con cargas nuevas.

Redpanda no compensa cuando:

  • Los clusters Kafka ya son estables y el equipo domina el ecosistema.

  • El coste de licencia es determinante. La versión de comunidad de Redpanda usa la Business Source License[7], que prohíbe revenderla como servicio de streaming gestionado a terceros y se convierte en Apache 2.0 cuatro años después de cada versión. Apache Kafka es Apache 2.0 puro desde el primer día.

  • Se necesita integración con cada conector y herramienta del ecosistema Kafka, que sigue siendo más profundo.

En 2025 ya no es una apuesta arriesgada elegir Redpanda para cargas nuevas; sigue siendo una migración costosa para cargas existentes.

Este artículo también está disponible en inglés: Redpanda: an alternative to Kafka with a different architecture.

Fuentes:

  1. Documentación oficial de Redpanda: arquitectura[3]
  2. Seastar, el framework thread-per-core usado por Redpanda y ScyllaDB[2]
  3. Redpanda: comparativa de rendimiento frente a Kafka (benchmark propio)[4]
  4. Jack Vanlightly: ¿se sostienen las cifras de Kafka vs. Redpanda?[5]
  5. Confluent Developer: KRaft, Kafka sin ZooKeeper[1]
  6. Redpanda: licencia BSL del código fuente[7]
  7. Docker Hub: tamaño de la imagen oficial de Redpanda[6]

Preguntas frecuentes

¿Tengo que cambiar mis aplicaciones o conectores de Kafka para pasar a Redpanda?

No. Redpanda reproduce el protocolo Kafka tal y como viaja por la red. Los clientes oficiales de Java, Python, Go o Rust, los conectores de Debezium y librerías como kafka-streams funcionan sin cambios. Solo conviene probar a fondo funcionalidades recientes de Kafka Streams, algunas transacciones idempotentes y el Schema Registry, cuya implementación en Redpanda es compatible pero no idéntica.

¿Es Redpanda realmente más rápido que Kafka?

Depende de la carga y de la configuración de acks. Redpanda reporta en sus propios benchmarks hasta diez veces mejor latencia en el percentil 99,99 en cargas mixtas, y gana con claridad en acks=1 con mensajes pequeños. Un análisis independiente muestra que con acks=all Kafka igualó o superó su p99 en parte de las pruebas y que Redpanda degradó latencia tras más de doce horas de carga sostenida. Mide en tu entorno.

¿Puedo usar Redpanda gratis sin problemas de licencia?

La versión de comunidad usa la Business Source License, que prohíbe revenderla como servicio de streaming gestionado a terceros y se convierte en Apache 2.0 cuatro años después de cada versión. Para uso interno no suele ser un obstáculo, pero si la licencia es determinante conviene recordar que Apache Kafka es Apache 2.0 puro desde el primer día.

Fuentes

  1. KRaft
  2. Seastar
  3. documentación de arquitectura de Redpanda
  4. comparativa publicada por Redpanda
  5. Jack Vanlightly
  6. Docker Hub
  7. Business Source License