MQTT Broker: qué es, cómo funciona y mejores opciones 2026
Un MQTT broker es el servidor central de mensajería de una red IoTITérminoIoT (Internet de las cosas)El IoT (Internet of Things) es la red de objetos físicos con sensores, software y conectividad que recogen e intercambian datos y actúan de forma autónoma.Ver perfil: recibe los datos que publican los dispositivos y los distribuye a todas las aplicaciones suscritas. Cada lectura de sensor, cada comando hacia un actuador y cada dato que ves en un dashboard pasa por él.
El escenario típico lo explica bien: una fábrica con 2.000 sensores de temperatura, vibración, presión y consumo eléctrico genera una lectura por sensor cada 30 segundos, y a la vuelta la plataforma central envía comandos a actuadores y PLCs en tiempo real. Algo tiene que gestionar ese flujo de mensajes de forma eficiente, o el sistema deja de ser operable mucho antes de llegar a producción.
Esta guía explica qué es el broker, cómo funciona, qué características importan en producción y qué opciones hay en 2026, de Mosquitto a los brokers gestionados en la nube.
¿Qué es MQTT y por qué domina el IoT?
MQTT (Message Queuing Telemetry Transport) es un protocolo de mensajería ligero diseñado para dispositivos con recursos limitados y redes de baja fiabilidad. Lo crearon Andy Stanford-Clark de IBM y Arlen Nipper en 1999 para monitorizar oleoductos en el desierto vía satélite: baja velocidad, alta latencia, conexiones inestables. Es el perfil de la mayoría de las redes IoT.
La especificación MQTT
ProtocoloMQTTEl protocolo pub/sub estándar del IoTVer perfil se basa en un modelo publicación/suscripción (pub/sub) que funciona al revés que el modelo cliente/servidor de HTTP:
- En HTTP, el cliente pregunta al servidor: "¿hay datos nuevos?" (polling). Ineficiente cuando los datos llegan con frecuencia variable.
- En MQTT, los dispositivos publican datos en un tópico. Las aplicaciones que quieren esos datos se suscriben al tópico. El broker intermedia: recibe publicaciones y las distribuye a todos los suscriptores.
Este desacoplamiento cambia cómo escala el sistema:
- Un sensor puede publicar datos sin saber cuántas aplicaciones los consumen.
- Puedes añadir 1.000 nuevos suscriptores sin tocar una línea de código del productor.
- Los dispositivos y las aplicaciones pueden reiniciarse independientemente sin perder mensajes.
MQTT opera sobre TCP/IP con un overhead mínimo: la cabecera fija es de solo 2 bytes. Comparado con HTTP, consume entre 10x y 100x menos ancho de banda para el mismo volumen de datos. Por eso se ha convertido en el protocolo de mensajería estándar del IoT, y por eso los comparativos de protocolos IoT como MQTT vs CoAP vs HTTP concluyen sistemáticamente que MQTT es la opción óptima para la mayoría de los casos de uso con sensores.
¿Qué es exactamente un MQTT broker?
El MQTT broker es el servidor central del sistema. Es el intermediario que:
- Acepta conexiones de dispositivos (publicadores) y aplicaciones (suscriptores).
- Recibe mensajes publicados en tópicos.
- Filtra y distribuye esos mensajes a todos los clientes suscritos al tópico correspondiente.
- Gestiona la autenticación y el control de acceso.
- Almacena mensajes temporalmente cuando un suscriptor está desconectado (QoSQTérminoQoS de MQTTEl QoS (Quality of Service) de MQTT define la garantía de entrega de un mensaje en tres niveles: 0 (como mucho una vez), 1 (al menos una vez) y 2 (exactamente una vez).Ver perfil 1 y 2, sesiones persistentes).
Los dispositivos no se comunican entre sí directamente. Todo pasa por el broker. Esta arquitectura centralizada facilita la seguridad, la monitorización y la gestión del sistema a escala.
Anatomía de un mensaje MQTT
Un mensaje MQTT tiene tres elementos:
- Tópico (topic): una cadena jerárquica que identifica el mensaje. Por ejemplo: `planta/linea-A/compresor-01/temperatura`. Los suscriptores pueden usar comodines: `planta/linea-A/#` (todo en línea A) o `planta/+/compresor-01/temperatura` (compresor-01 en cualquier línea).
- Payload: el contenido del mensaje. Puede ser texto plano, JSON, binario, Protobuf... MQTT no impone formato.
- QoS (Quality of Service): define la garantía de entrega:
- QoS 0: "fire and forget", sin confirmación ni reintento
- QoS 1: "al menos una vez", con confirmación del broker y posible duplicado
- QoS 2: "exactamente una vez", entrega garantizada sin duplicados a cambio de mayor overhead
Características clave de un MQTT broker en producción
No todos los brokers son iguales. Para un despliegue IoT en producción, estos son los factores que determinan si un broker aguanta la carga real.
Escalabilidad y throughput
¿Cuántos mensajes por segundo puede procesar? ¿Cuántas conexiones simultáneas soporta? Un broker de producción para una instalación industrial media debe manejar al menos 10.000 mensajes/segundo y 50.000 conexiones simultáneas sin degradación. Los brokers enterprise modernos (EMQXETérminoEMQXEMQX es un broker MQTT open source de alta escala (escrito en Erlang) para producción IoT, con clustering y soporte multiprotocolo.Ver perfil, HiveMQ) escalan horizontalmente a millones de conexiones mediante clustering.
Persistencia y sesiones
Cuando un dispositivo IoT pierde la conexión por un fallo de red, un reinicio o un problema de batería, ¿qué ocurre con los mensajes publicados mientras estaba desconectado? Con sesiones persistentes (QoS 1/2 y `cleanSession=false`), el broker almacena los mensajes pendientes y los entrega cuando el dispositivo se reconecta. Imprescindible para sensores en ubicaciones con conectividad intermitente.
Last Will and Testament (LWT)
El mecanismo LWT (Última Voluntad) permite a un dispositivo registrar, en el momento de la conexión, un mensaje que el broker publicará automáticamente si la conexión cae de forma inesperada. Así las aplicaciones suscriptoras detectan al instante que un dispositivo se ha desconectado, sin polling ni timeouts artificiales. En sistemas industriales, esta señal de presencia es la base de la monitorización de estado.
Autenticación y autorización
Un broker de producción debe soportar:
- Autenticación por usuario/contraseña o certificados TLS de cliente (mTLS)
- Autorización por ACL (Access Control Lists): qué clientes pueden publicar/suscribirse en qué tópicos
- Integración con directorios LDAP/AD o sistemas de identidad externos
Sin un control de acceso estricto a nivel de tópico, cualquier dispositivo comprometido puede leer o inyectar datos en cualquier parte del sistema. La ciberseguridad OT e IoT empieza en el broker.
Retención de mensajes (Retained Messages)
Un mensaje retenido es el último valor publicado en un tópico que el broker almacena indefinidamente. Cuando un nuevo suscriptor se conecta, recibe inmediatamente el último valor retenido sin esperar a la próxima publicación. Sin esto, un dashboard recién abierto se quedaría en blanco hasta el siguiente ciclo de transmisión del sensor.
Bridging entre brokers
En arquitecturas distribuidas con múltiples plantas o países, es habitual tener brokers locales en cada instalación con un broker central en la nube. El MQTT bridge sincroniza tópicos entre brokers, permitiendo que los datos fluyan de instalaciones locales al sistema central sin exponer directamente los brokers de planta a Internet.
Seguridad: los vectores de ataque más comunes
Un broker MQTTBTérminoBroker MQTTUn broker MQTT es el servidor central que recibe los mensajes de los publishers y los distribuye a los subscribers según los temas. Ejemplos: Mosquitto, EMQX, HiveMQ.Ver perfil mal configurado expone toda la infraestructura IoT. Lo que no puedes ignorar:
- Broker público sin autenticación: existen brokers públicos de prueba (broker.hivemq.com, test.mosquitto.org) que aceptan conexiones anónimas. Nunca usar en producción ni con datos reales.
- Comunicación sin TLS: los mensajes MQTT sin cifrado viajan en texto plano. Cualquier actor con acceso a la red puede leer o inyectar mensajes. TLS 1.3 es obligatorio en producción.
- ACL demasiado permisivas: si todos los dispositivos pueden publicar y suscribirse en todos los tópicos, un sensor comprometido puede inyectar datos falsos en toda la red. Las ACL deben restringir cada cliente exactamente a los tópicos que necesita.
- Credenciales por defecto o hardcoded: las contraseñas de los dispositivos MQTT deben rotarse periódicamente y almacenarse de forma segura.
Ver la guía de ciberseguridad OT para IA industrial e IoT para un análisis detallado de vectores de ataque y contramedidas a nivel de infraestructura.
Los principales MQTT brokers en 2026
Eclipse Mosquitto
Mosquitto es el broker open source de referencia. Ligero, eficiente, ampliamente documentado y con soporte de la comunidad Eclipse. Buena opción para proyectos pequeños y medianos, desarrollo, pruebas y despliegues edge donde los recursos son limitados. Su límite: no escala horizontalmente (single-node) y el clustering requiere configuración manual avanzada.
- Ideal para: Raspberry Pi
EmpresaRaspberry PiSingle-board computers y microcontroladores RP2040/RP2350Ver perfil, gateways edge, proyectos con <10.000 conexiones - Licencia: EPL/EDL (open source)
EMQX
EMQX es un broker de alto rendimiento escrito en Erlang, diseñado para millones de conexiones concurrentes con baja latencia. Arquitectura distribuida nativa. Soporta clustering automático, persistencia de mensajes, autenticación avanzada (JWT, LDAP, OAuth), reglas de procesamiento integradas (Rule Engine) y bridging. Muy presente en telco, automoción e industria a gran escala.
- Ideal para: despliegues industriales de gran escala, plataformas IoT multi-tenant
- Licencia: open source (Community) + Enterprise
HiveMQ
HiveMQ está orientado al enterprise, con foco en conformidad, soporte certificado y extensibilidad mediante plugins. Muy utilizado en automoción (conectividad vehicular) y en sectores con requerimientos de auditoría estrictos como saludSIndustriaSaludVer perfil o energía. Clustering nativo, alta disponibilidad.
- Ideal para: proyectos enterprise con SLA exigentes, sectores regulados
- Licencia: comercial (con edición gratuita limitada)
VerneMQ y NanoMQ
VerneMQ: open source, arquitectura distribuida similar a EMQX, buena opción para clusters de alta disponibilidad sin coste de licencia. NanoMQ: diseñado específicamente para edge computingETérminoEdge computingEl edge computing procesa datos cerca de su origen (dispositivo o gateway) en lugar del cloud, reduciendo latencia, ancho de banda y dependencia de conexión.Ver perfil y gateways embebidos con recursos muy limitados (escrito en C, ~200 KB de footprint).
On-premise vs cloud: dónde desplegar el broker
La elección entre un broker en infraestructura propia o en la nube depende de varios factores. Para aplicaciones industriales con datos sensibles, latencia crítica o requisitos de conformidad estrictos, un broker on-premise en el datacenter propio o en el centro de producción es la opción correcta. Para proyectos con dispositivos distribuidos geográficamente, equipos sin experiencia en infraestructura o necesidades de escalado rápido, los brokers gestionados en la nube (AWS IoT CoreATérminoAWS IoT CoreAWS IoT Core es el servicio gestionado de Amazon Web Services para conectar, autenticar y gestionar dispositivos IoT a escala mediante MQTT sobre la infraestructura de AWS.Ver perfil, Azure IoT HubATérminoAzure IoT HubAzure IoT Hub es el servicio gestionado de Microsoft Azure para la conectividad bidireccional con dispositivos IoT, con Device Twins e integración con el ecosistema Azure.Ver perfil, HiveMQ Cloud, EMQX Cloud) eliminan la carga operativa.
Muchos proyectos de producción adoptan una arquitectura híbrida: brokers locales en cada instalación con bridging a un broker central en la nube para consolidación y análisis.
MQTT en la arquitectura IoT: dónde encaja el broker
En una arquitectura IoT típica de 2026, el MQTT broker ocupa la capa central de mensajería, entre los dispositivos de campo y la plataforma de aplicación:
Los sensores IoT de temperatura, vibración, CO₂ o nivel publican sus lecturas en el broker cada N segundos o cuando se produce un evento. El gateway IoT actúa como agregador y traductor de protocolo: convierte datos de sensores LoRaWAN, ModbusMProtocoloModbusEl bus de campo industrial más extendidoVer perfil o BLEBTérminoBluetooth Low Energy (BLE)Bluetooth Low Energy (BLE) es la variante de bajo consumo de Bluetooth, para enviar pocos datos de forma intermitente con mínima batería. Domina wearables y proximidad. Lo mantiene el Bluetooth SIG.Ver perfil al formato MQTT antes de enviarlos al broker central. La plataforma IoT se suscribe a los tópicos relevantes, procesa los datos y los almacena para visualización y análisis.
En la dirección inversa, la plataforma puede publicar comandos (abrir válvula, reiniciar dispositivo, cambiar umbral de alerta) que los actuadores reciben como suscriptores del tópico correspondiente.
Para proyectos que requieren procesamiento local o que operan en zonas con conectividad intermitente, tiene sentido desplegar un broker Mosquitto directamente en el gateway, que actúa como broker local y hace bridging al broker central en la nube. Es el patrón habitual de procesamiento en el edge; lo analizamos en Edge AI en IoT industrial.
¿Estás diseñando la arquitectura de mensajería para tu proyecto IoT? Habla con nuestro equipo de arquitectura →
MQTT y Sparkplug: el estándar industrial avanzado
Sparkplug es una especificación de payload y namespace construida sobre MQTT, desarrollada inicialmente por Cirrus Link Solutions y ahora mantenida por la Eclipse Foundation. Diseñada específicamente para SCADA y automatización industrial, define cómo estructurar los tópicos y los mensajes para garantizar interoperabilidad entre dispositivos de distintos fabricantes.
Las cinco capacidades que Sparkplug requiere del broker MQTT:
- Arquitectura pub/sub desacoplada: productores y consumidores operan independientemente
- Session State Awareness: el broker mantiene el estado de sesión de los dispositivos para re-entrega tras reconexión (vía LWT)
- Namespace unificado: un esquema de tópicos estandarizado (`spBv1.0/[GroupID]/[MessageType]/[EdgeNodeID]/[DeviceID]`)
- Repositorio central de datos (CDR): el broker como hub de todos los datos industriales en tiempo real
- Single Source of Truth: el broker almacena el estado actualizado de todos los dispositivos como única referencia
Sparkplug importa sobre todo en entornos donde coexisten PLCs, SCADA y plataformas IoT de distintos fabricantes, porque define un contrato de datos común entre todos ellos.
MQTT y otros protocolos IoT: NB-IoT y LoRaWAN
MQTT no compite con LoRaWAN
ProtocoloLoRaWANLPWAN abierta de largo alcance y bajo consumoVer perfil ni con NB-IoT
ProtocoloNB-IoTLPWAN celular standardizada por 3GPP — cobertura operadorVer perfil: operan en capas diferentes. LoRaWAN y NB-IoT son protocolos de acceso al medio (radio): definen cómo los bits viajan por el aire desde el sensor hasta el gateway o la red de operadora. MQTT es un protocolo de mensajería: define cómo los datos se estructuran y distribuyen entre aplicaciones una vez que han llegado a la red IP.
En la práctica, los datos de un sensor LoRaWAN llegan al Network Server del operador (ChirpStackCTérminoChirpStackChirpStack es un Network Server LoRaWAN open source para desplegar y gestionar redes LoRaWAN privadas de extremo a extremo.Ver perfil, The Things Network, etc.), que los reenvía vía MQTT al broker de la plataforma. Los datos de un sensor NB-IoT llegan al servidor de la operadora y se entregan a la plataforma también vía MQTT o CoAPCTérminoCoAPCoAP (Constrained Application Protocol) es un protocolo web tipo REST sobre UDP para dispositivos muy limitados, definido en el RFC 7252 del IETF.Ver perfil. MQTT actúa como el idioma común de las capas superiores, independientemente del radio access protocol utilizado.
Cómo implementa Cloud Studio IoT el MQTT broker
La plataforma Cloud Studio IoT integra un broker MQTT de alta disponibilidad como componente central de su arquitectura de mensajería. Todos los dispositivos y gateways conectados a la plataforma se comunican vía MQTT con TLS 1.3 obligatorio, autenticación por certificado o token, y ACLs configuradas por tenant para garantizar la segregación de datos entre clientes.
Para deployments industriales complejos, la plataforma soporta el protocolo Sparkplug B, lo que permite integrar directamente equipos SCADA y PLCs que ya hablan este estándar, sin capas de traducción adicionales.
El broker es transparente para el usuario final de la plataforma: los integradores y fabricantes que usan Cloud Studio IoT no necesitan gestionarlo directamente porque está integrado, monitorizado y escalado automáticamente. Para quienes necesitan control completo, como empresas con políticas de datos estrictas o infraestructura on-premise, también ofrecemos el despliegue de la plataforma completa, broker incluido, en el entorno propio del cliente.
Para ver cómo se posiciona la plataforma frente a otras alternativas, consulta Cloud Studio IoT vs ThingsBoard y las razones para adoptar una plataforma IoT.
Si quieres evaluar la arquitectura MQTT correcta para tu proyecto, contacta con nuestro equipo técnico.
Preguntas frecuentes sobre MQTT brokers
¿Qué diferencia hay entre MQTT y HTTP para IoT?
HTTP usa un modelo petición/respuesta: el cliente pregunta, el servidor responde. Para monitorización IoT, esto implica polling constante que consume batería y ancho de banda. MQTT usa pub/sub: los datos llegan al suscriptor en el momento en que se publican, sin petición. El overhead de cabecera de MQTT es de 2 bytes; el de HTTP mínimo ronda los 200-500 bytes. Para dispositivos con batería y redes de baja velocidad, MQTT es la única opción razonable.
¿Puedo usar MQTT sin broker?
No. El broker es el componente central del modelo pub/sub. Sin broker, los dispositivos no tienen a dónde publicar ni de dónde suscribirse. Existen variantes como MQTT-SN (para redes de sensores sin TCP/IP) que usan gateways especializados, pero el concepto de intermediario central permanece.
¿Cuántos dispositivos puede gestionar un broker MQTT?
Depende del broker y de la infraestructura. Mosquitto en un servidor modesto maneja 50.000-100.000 conexiones. EMQX o HiveMQ en cluster escalan a millones de conexiones concurrentes. Para proyectos industriales típicos, de cientos a decenas de miles de sensores, cualquier broker enterprise moderno es suficiente si está correctamente dimensionado.
¿Es MQTT seguro?
MQTT con TLS 1.3, autenticación por certificado y ACLs estrictas es seguro para producción. El problema no es el protocolo sino las implementaciones mal configuradas: brokers sin TLS, sin autenticación, o con ACLs demasiado permisivas. La seguridad en MQTT es una decisión de configuración, no una limitación del protocolo.
¿Qué es MQTT 5.0 y en qué se diferencia de MQTT 3.1.1?
MQTT 5.0 (publicado en 2019) añade capacidades importantes: propiedades de mensaje extendidas, códigos de razón para respuestas, subscripciones compartidas (para balanceo de carga entre múltiples consumidores del mismo tópico), expiración de mensajes, y mejoras en el manejo de sesiones. La mayoría de los brokers y clientes modernos ya soportan ambas versiones.
¿MQTT funciona con LoRaWAN?
Sí, pero en capas diferentes. LoRaWAN gestiona la transmisión radio desde el sensor hasta el gateway y el network server. El network server LoRaWAN (ChirpStack, TTNTTérminoThe Things Network (TTN)The Things Network es una red LoRaWAN comunitaria y gratuita, con cobertura colaborativa global mantenida por una comunidad open source.Ver perfil) reenvía los mensajes a la plataforma de aplicación usando MQTT como protocolo de entrega. Son complementarios, no alternativos.
Conclusión: el broker MQTT como infraestructura crítica
Todos los datos que generan los sensores, todos los comandos que reciben los actuadores y toda la visibilidad que tienen los dashboards pasan por el MQTT broker. Tratarlo como un detalle de implementación sale caro.
Lo que conviene recordar:
- MQTT domina el IoT por su modelo pub/sub y su overhead mínimo (cabecera de 2 bytes).
- El broker es el servidor central: autentica, filtra, distribuye y almacena mensajes.
- En producción importan la escalabilidad, las sesiones persistentes, LWT, las ACL y el bridging.
- Mosquitto para edge y proyectos medianos; EMQX y HiveMQ para escala enterprise; gestionados (AWS IoT Core, HiveMQ Cloud, EMQX Cloud) si no quieres operar infraestructura.
- TLS 1.3 + ACLs estrictas no son opcionales.
Si estás diseñando una arquitectura IoT y quieres elegir bien desde el principio, nuestro equipo técnico puede ayudarte.
¿Listo para Transformar tu Negocio?
Contáctanos para descubrir cómo Cloud Studio IoT puede ayudarte a alcanzar tus objetivos.