Comparativa de brokers MQTT open source: Mosquitto, EMQX, VerneMQ y NanoMQ

Esta comparativa de brokers MQTT open source analiza cuatro proyectos muy utilizados, Eclipse Mosquitto, EMQX, VerneMQ y NanoMQ, desde el punto de vista de quien tiene que operarlos. Verás en qué destaca cada broker, cuánto esfuerzo operativo te exige y cómo levantar cada uno en local en pocos minutos. Al final deberías saber cuál encaja en tu proyecto, o si te compensa más delegar la operación en un broker MQTT gestionado.

¿Por qué comparar brokers MQTT open source?

Todo despliegue MQTT necesita un broker: el servidor que acepta conexiones, autentica a los clientes y enruta cada mensaje publicado a todos los suscriptores que coinciden. Si quieres repasar ese papel, lee qué hace un broker MQTT. El protocolo está estandarizado, así que cualquier cliente que cumpla el estándar puede hablar con cualquier broker que también lo cumpla. Lo que diferencia a los brokers es todo lo que rodea al protocolo: cómo escalan, cómo almacenan las sesiones, cómo se configura la autenticación, cómo se comportan durante las actualizaciones y cuánto tiempo tuyo necesitan.

Los cuatro proyectos siguientes son maduros, se usan en producción en algún lugar e implementan MQTT 3.1.1 y MQTT 5.0. Ninguno es "el mejor" en abstracto. La elección correcta depende del número de conexiones, de si necesitas clustering, de lo que tu equipo ya conoce y de las condiciones de licencia que acepta tu organización.

Los cuatro brokers de un vistazo

Eclipse Mosquitto

Mosquitto es el punto de referencia con el que empieza la mayoría. Está escrito en C, se mantiene bajo la Eclipse Foundation y es lo bastante pequeño como para ejecutarse en una Raspberry Pi o dentro de un contenedor con unos pocos megabytes de memoria. La configuración es un único archivo de texto, la autenticación se gestiona con un archivo de contraseñas o con el plugin de seguridad dinámica, y el bridging permite que una instancia de Mosquitto reenvíe topics a otro broker.

El principal límite de arquitectura es que Mosquitto se ejecuta como un único nodo. No tiene clustering integrado, así que la alta disponibilidad requiere un mecanismo de failover externo y un plan para el estado de las sesiones. Para una única instalación, un laboratorio, un gateway en el edge o unos pocos miles de dispositivos en un servidor bien dimensionado, suele ser perfectamente suficiente.

EMQX

EMQX está construido sobre Erlang/OTP y diseñado desde el principio en torno al clustering. Varios nodos forman un único broker lógico, lo que le permite repartir números de conexiones muy elevados entre máquinas. Incluye un dashboard web, un completo sistema de autenticación y autorización, y un rule engine e integraciones de datos integrados en su conjunto de funciones. Hay un operador de Kubernetes disponible para despliegues en clúster.

La licencia merece atención: EMQX ha cambiado su modelo de licencias a lo largo de sus versiones, y las condiciones de las versiones más recientes difieren de las antiguas versiones open source. Lee la licencia actual en el sitio web de EMQX y confirma que se ajusta a tu uso antes de estandarizar sobre ella.

VerneMQ

VerneMQ también está construido sobre Erlang y ofrece clustering sin maestro (masterless), hooks de plugins para autenticación y autorización y funciones como los mountpoints para separar espacios de topics. El código fuente se publica bajo la licencia Apache 2.0. Sus paquetes precompilados e imágenes de contenedor oficiales tienen sus propias condiciones (la imagen de Docker te pide aceptar un EULA mediante una variable de entorno), así que comprueba qué distribución estás usando. Como con cualquier proyecto, revisa la actividad reciente de versiones y los canales de soporte de la comunidad antes de comprometerte.

NanoMQ

NanoMQ, del equipo de EMQ, es un broker ligero escrito en C sobre la librería de mensajería NNG. Está orientado a dispositivos edge y gateways: huella reducida, rendimiento multihilo en hardware modesto y bridging hacia un broker superior. Encaja de forma natural cuando quieres un broker local en un PC industrial o un gateway que reenvíe topics seleccionados a un broker central o en la nube.

Tabla comparativa de funciones y operación

La tabla resume la arquitectura y las características operativas típicas. Confirma siempre los detalles en la documentación actual de cada proyecto, ya que las funciones cambian entre versiones.

Destacan dos observaciones. Primero, los brokers de un solo nodo son más sencillos de operar, pero te obligan a resolver tú la disponibilidad. Segundo, los brokers en clúster resuelven la disponibilidad y la escala, pero añaden piezas móviles: descubrimiento de nodos, particiones de red, actualizaciones progresivas y monitorización consciente del clúster.

Prueba cada broker en local con Docker

La forma más rápida de formarte una opinión es ejecutar cada broker y conectar un cliente. Los siguientes comandos son solo para pruebas locales, con acceso anónimo activado. No expongas estas configuraciones a Internet.

# Mosquitto 2.x needs an explicit listener to accept non-localhost connections
mkdir -p mosquitto/config
cat > mosquitto/config/mosquitto.conf <<'EOF'
listener 1883
allow_anonymous true
EOF
docker run -d --name mosquitto -p 1883:1883 \
  -v "$PWD/mosquitto/config:/mosquitto/config" eclipse-mosquitto:2

# EMQX (dashboard on http://localhost:18083)
docker run -d --name emqx -p 1884:1883 -p 18083:18083 emqx/emqx:latest

# VerneMQ (accept the image EULA and allow anonymous for a local test)
docker run -d --name vernemq -p 1885:1883 \
  -e DOCKER_VERNEMQ_ACCEPT_EULA=yes \
  -e DOCKER_VERNEMQ_ALLOW_ANONYMOUS=on vernemq/vernemq

# NanoMQ
docker run -d --name nanomq -p 1886:1883 emqx/nanomq:latest

Después ejecuta la misma prueba de publicación y suscripción contra cada puerto:

for port in 1883 1884 1885 1886; do
  mosquitto_sub -h localhost -p $port -i sub-$port -t 'test/compare' -C 1 -W 5 &
  sleep 1
  mosquitto_pub -h localhost -p $port -i pub-$port -t 'test/compare' -m "hello from $port"
  wait
done

Cada suscriptor debería imprimir un mensaje y terminar. Cuando eso funcione, empieza lo interesante: activa la autenticación, añade TLS, reinicia el contenedor mientras un cliente mantiene una sesión persistente y observa qué sobrevive. Ese ejercicio te dice más sobre la operación del día a día que cualquier lista de funciones.

Lo que la lista de funciones no te cuenta

TLS y certificados

Todos los brokers admiten TLS, pero alguien tiene que obtener los certificados, renovarlos antes de que caduquen y recargar el broker sin desconectar todos los dispositivos. Automatizarlo con herramientas ACME es perfectamente factible, y también es una fuente clásica de caídas cuando un trabajo de renovación falla en silencio.

Actualizaciones y conexiones de larga duración

Las conexiones MQTT duran días o meses. Reiniciar un broker de un solo nodo desconecta a todos los clientes a la vez, y todos se reconectan en el mismo instante. Los brokers en clúster pueden actualizarse nodo a nodo, pero los clientes del nodo que se reinicia siguen teniendo que reconectarse. Planifica un backoff de reconexión aleatorio en el lado del dispositivo, elijas el broker que elijas.

Monitorización y capacidad

Necesitas vigilar el número de conexiones, las tasas de mensajes, los mensajes descartados, la memoria y los descriptores de archivo. Mosquitto publica estadísticas en los topics $SYS/; los brokers en clúster exponen API HTTP y endpoints de métricas. En cualquier caso, los dashboards y las reglas de alerta los construyes tú. Nuestra guía de monitorización de brokers MQTT enumera las métricas que merece la pena seguir.

Operaciones de seguridad

Los puertos MQTT expuestos atraen rápidamente a los escáneres. Endurecer el sistema implica desactivar el acceso anónimo, limitar los inicios de sesión fallidos, mantener actualizados el broker y la imagen base, y revisar la configuración tras cada actualización. El artículo de buenas prácticas de seguridad MQTT cubre la parte del cliente de ese panorama.

Cómo elegir entre ellos

Usa estas preguntas como ruta de decisión:

1. ¿Cuántas conexiones simultáneas esperas dentro de dos años? Si un único servidor bien dimensionado las cubre con holgura, Mosquitto te simplifica la vida. Si no, mira las opciones con clustering.
2. ¿Necesitas el broker en el edge? Para gateways y PC industriales, Mosquitto o NanoMQ son opciones naturales, normalmente con bridge hacia un broker central.
3. ¿Es la alta disponibilidad un requisito imprescindible? Entonces ejecuta un broker en clúster o diseña un failover externo para uno de un solo nodo, incluido lo que ocurre con las sesiones persistentes.
4. ¿Qué condiciones de licencia puede aceptar tu organización? Lee la licencia actual de la versión y la distribución exactas que vas a desplegar.
5. ¿Quién estará de guardia? Un broker es infraestructura. Si nadie del equipo quiere encargarse de los parches, los certificados y los avisos a las 3 de la madrugada, tenlo en cuenta desde ahora.

Si la quinta pregunta te hace dudar, compara el esfuerzo con un análisis de broker MQTT autoalojado vs gestionado antes de decidir.

Cuándo tiene más sentido un broker MQTT gestionado

Los brokers open source son un software excelente. El coste de operarlos es sobre todo tiempo de personas: configurar TLS, construir la monitorización, gestionar las actualizaciones, ajustar los límites y responder a incidentes. Para muchos equipos IoT, ese tiempo está mejor invertido en los dispositivos y las aplicaciones.

Un broker MQTT gestionado traslada esas tareas al proveedor. Con ConnectMQ creas un broker en el portal y recibes un usuario, una contraseña y un client ID. Los endpoints están listos en TCP 1883, TLS 8883, WebSocket 8083 y Secure WebSocket 8084 (ruta /mqtt) con un certificado de Let's Encrypt, y los clientes MQTT 3.1.1 y MQTT 5.0 funcionan sin cambios. Como MQTT es un estándar, el mismo código cliente que probaste contra Mosquitto o EMQX se conecta a ConnectMQ cambiando el host, el puerto y las credenciales.

ConnectMQ también añade herramientas que de otro modo tendrías que montar tú: un cliente MQTT en el navegador, un explorador de topics en vivo, un dashboard, una vista de dispositivos organizada por niveles ISA-95 y reglas de alerta por umbral con registro de alertas. Los planes van desde un nivel Serverless gratuito en un clúster compartido hasta clústeres aislados Dedicated y BYOC en tu propia cuenta cloud, de modo que el modelo de alojamiento puede seguir a tus requisitos. La guía de brokers MQTT en la nube explica cómo se comparan esos modelos.

Un patrón sensato es el híbrido: mantener Mosquitto o NanoMQ en el edge para la resiliencia local y reenviar por bridge topics seleccionados a un broker alojado que usen tus aplicaciones y dashboards en la nube.

Prueba contra un broker alojado en minutos

Antes de elegir, apunta tu cliente actual a un broker alojado y compara la experiencia con tus contenedores locales. El servidor MQTT público gratuito en broker.connectmq.com, solo para pruebas y no para datos de producción, no necesita cuenta; usa un client ID y un prefijo de topic únicos y recuerda que cualquiera puede leer los topics públicos.

mosquitto_sub -h broker.connectmq.com -p 1883 -i cmp-sub-7f3a \
  -t 'connectmq/demo/7f3a/compare' -v &
mosquitto_pub -h broker.connectmq.com -p 1883 -i cmp-pub-7f3a \
  -t 'connectmq/demo/7f3a/compare' -m 'hello from the comparison test'

Para datos de producción, crea un broker privado y conéctate por TLS en el puerto 8883 con tus propias credenciales.

Empieza con ConnectMQ

Si prefieres dedicar tu tiempo a los dispositivos y las aplicaciones en lugar de a operar brokers, crea un broker Serverless gratuito en app.connectmq.com. No necesitas tarjeta de crédito y más adelante puedes pasar a Dedicated o BYOC sin cambiar el código de tus clientes MQTT.

Preguntas frecuentes

¿Qué broker MQTT open source es mejor para principiantes?

Mosquitto suele ser el punto de partida más sencillo. Se instala en minutos, usa un único archivo de configuración legible y está documentado en innumerables tutoriales.

¿Se puede montar Mosquitto en clúster?

No de forma nativa. Mosquitto se ejecuta como un único nodo; puedes conectar instancias mediante bridges o montar un failover externo, pero para un verdadero clúster de varios nodos tendrías que recurrir a un broker diseñado para clustering.

¿Sigue siendo EMQX open source?

La licencia de EMQX ha cambiado entre versiones, así que la respuesta depende de la versión que despliegues. Consulta la licencia publicada con la versión exacta que piensas usar.

¿Puedo pasar más adelante de un broker open source a uno gestionado?

Sí. MQTT es un estándar, así que los clientes normalmente solo necesitan un nuevo host, puerto y credenciales. Revisa las funciones propias del broker de las que dependes, como rule engines o plugins, porque esas no se trasladan automáticamente.