MQTT vs AMQP: diferencias, casos de uso y rendimiento

La cuestión MQTT vs AMQP surge cada vez que un equipo que construye dispositivos conectados también ejecuta servicios backend sobre un broker de mensajería como RabbitMQ. Ambos protocolos usan broker, ambos funcionan sobre TCP y ambos ofrecen confirmaciones de entrega, pero se diseñaron para tareas muy distintas. Esta guía compara los modelos de broker, el enrutamiento, las garantías y la huella del cliente, y termina con una regla práctica sobre cuándo encaja cada uno en tu arquitectura.

De dónde viene cada protocolo

MQTT se diseñó para la telemetría de equipos remotos a través de enlaces poco fiables y de bajo ancho de banda. Sus prioridades son un cliente diminuto, un formato de paquete pequeño y un modelo sencillo: los clientes publican en topics jerárquicos y se suscriben con comodines. Es un estándar OASIS, con las versiones 3.1.1 y 5.0 ampliamente usadas.

AMQP (Advanced Message Queuing Protocol) surgió del sector financiero, donde la prioridad era una mensajería fiable e interoperable entre sistemas de negocio. Tiene dos linajes bastante distintos. AMQP 0-9-1 es el modelo que la mayoría de desarrolladores conoce por RabbitMQ, con exchanges, bindings y colas. AMQP 1.0 es el estándar OASIS e ISO, un protocolo de transferencia peer-to-peer más general que usan servicios como Azure Service Bus y que admiten brokers como Apache ActiveMQ Artemis. Cuando alguien dice "AMQP", conviene preguntar a cuál se refiere.

MQTT vs AMQP de un vistazo

Aspecto	MQTT	AMQP 0-9-1 (estilo RabbitMQ)	AMQP 1.0
Modelo central	Topics con publish/subscribe	Los exchanges enrutan a colas mediante bindings	Enlaces entre nodos; la semántica del broker la define la implementación
Enrutamiento	Topics jerárquicos, comodines `+` y `#`	Exchanges direct, topic, fanout, headers	Direcciones y filtros, específicos del broker
Colas	Sin colas explícitas (colas de sesión por cliente)	Colas explícitas, con nombre y duraderas	Nodos definidos por el broker
Garantías de entrega	QoS 0, 1, 2	Acks, publisher confirms, transacciones	Modos de liquidación, como máximo una vez y al menos una vez
Reparto de trabajo	Suscripciones compartidas (MQTT 5)	Consumidores en competencia sobre una cola	Receptores en competencia sobre un nodo
Control de flujo	Receive maximum (MQTT 5)	Prefetch (basic.qos)	Control de flujo de enlace basado en créditos
Tamaño de cabecera	Muy pequeño, cabecera fija mínima de 2 bytes	Tramas y propiedades más grandes	Codificación más grande y con tipado rico
Huella del cliente	Cabe en microcontroladores	Cómodo en servidores y gateways	Cómodo en servidores y gateways
Entorno típico	Dispositivos, gateways, navegadores, apps móviles	Microservicios backend, colas de tareas	Integración empresarial, servicios de mensajería en la nube

Modelo de broker y enrutamiento

Un broker MQTT enruta únicamente por topic. Un publicador envía a plant1/line2/press4/temperature, y cada cliente cuyo filtro de suscripción coincida recibe una copia. No hay configuración de enrutamiento aparte; la jerarquía de topics es la tabla de enrutamiento. Eso hace que MQTT sea fácil de adoptar y de razonar, sobre todo cuando los topics siguen una estructura como ISA-95 o un Unified Namespace. El artículo sobre el modelo publish/subscribe de MQTT explica el desacoplamiento con más detalle.

AMQP 0-9-1 separa adónde se envían los mensajes (un exchange) de dónde se almacenan (las colas). Los bindings conectan ambos con reglas. Un exchange de tipo topic se comporta un poco como los comodines de MQTT, un exchange fanout copia a todas las colas vinculadas y un exchange direct enruta por una clave exacta. Esta flexibilidad es muy potente para flujos backend, como repartir un evento de pedido entre las colas de facturación, envíos y analítica, cada una con su propia retención y sus consumidores. El precio es tener más conceptos que aprender y más configuración que gestionar.

Garantías de entrega

MQTT ofrece tres niveles de QoS: como máximo una vez (QoS 0), al menos una vez (QoS 1) y exactamente una vez entre cliente y broker (QoS 2). Las sesiones persistentes permiten al broker guardar mensajes QoS 1 y 2 para un suscriptor que está temporalmente offline. Para repasarlo, consulta niveles de QoS de MQTT explicados.

AMQP te da confirmaciones de consumidor, confirmaciones negativas con reencolado, publisher confirms y, en 0-9-1, transacciones. Los mensajes permanecen en una cola duradera hasta que un consumidor los confirma explícitamente, que es justo lo que quieres para trabajos como "genera esta factura", que debe procesar exactamente un worker y reintentarse si falla.

En la práctica, ambos pueden entregar de forma fiable. La diferencia está en el énfasis: MQTT está optimizado para flujos de estado y eventos hacia muchos suscriptores; AMQP, para elementos de trabajo duraderos que gestionan consumidores en competencia.

Rendimiento y huella

Ninguno de los dos protocolos es "más rápido" en abstracto. El throughput depende mucho más de la implementación del broker, la configuración de persistencia, el tamaño de los mensajes y el modo de confirmación que del formato en la red.

Donde los protocolos se diferencian claramente es en la huella. Una biblioteca cliente MQTT cabe holgadamente en un ESP32 o un microcontrolador similar, y la sobrecarga por mensaje es mínima, algo importante en enlaces celulares y por satélite. Los clientes AMQP son más pesados, las tramas llevan más metadatos y el establecimiento de la conexión implica más negociación. En un servidor esa diferencia es irrelevante; en un sensor alimentado por batería es decisiva.

MQTT también gestiona bien un número muy grande de conexiones mayoritariamente inactivas, que es la forma habitual de una flota IoT. Los brokers AMQP suelen estar ajustados para menos conexiones, pero más ocupadas, procedentes de servicios.

Arquitecturas típicas

La respuesta más habitual en el mundo real a MQTT vs AMQP es "ambos, en capas distintas":

Los dispositivos, gateways y dashboards se conectan a un broker MQTT.
Un servicio backend se suscribe a los topics MQTT relevantes, por ejemplo plant1/+/+/telemetry.
Ese servicio valida y enriquece los datos, y luego publica elementos de trabajo en una cola AMQP para su procesamiento posterior, como facturación, gestión de tickets o actualizaciones del ERP.

Aquí tienes un bridge mínimo en Python que se suscribe por MQTT y publica en una cola de RabbitMQ con pika. Se ejecuta como proceso propio, así que tú controlas el agrupamiento, el filtrado y la gestión de errores.

import json
import uuid

import paho.mqtt.client as mqtt
import pika

PREFIX = "connectmq/demo/replace-me"

amqp = pika.BlockingConnection(pika.ConnectionParameters("localhost"))
channel = amqp.channel()
channel.queue_declare(queue="telemetry", durable=True)

def on_connect(client, userdata, flags, reason_code, properties):
    print("MQTT connected:", reason_code)
    client.subscribe(f"{PREFIX}/+/telemetry", qos=1)

def on_message(client, userdata, msg):
    try:
        body = json.loads(msg.payload)
    except json.JSONDecodeError:
        print("skipping invalid payload on", msg.topic)
        return
    body["topic"] = msg.topic
    channel.basic_publish(
        exchange="",
        routing_key="telemetry",
        body=json.dumps(body),
        properties=pika.BasicProperties(delivery_mode=2),  # persistente
    )

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"amqp-bridge-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()

En producción, conéctate a tu broker privado por TLS en el 8883 con client.tls_set() y client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD"), y usa el client ID emitido con esas credenciales. Como la conexión bloqueante de pika no es thread-safe, mantén todas las llamadas AMQP dentro del hilo del bucle de red de MQTT, como se muestra, o pasa los mensajes a una cola que consuma un hilo AMQP dedicado.

Cuándo elegir MQTT

Los clientes son microcontroladores, gateways, apps móviles o navegadores.
Las conexiones son poco fiables, de pago por uso o de alta latencia.
Muchos consumidores necesitan el mismo flujo de telemetría o de estado.
Necesitas detectar el estado online/offline (keep alive y Last Will) y conocer los últimos valores (mensajes retenidos).
Quieres un modelo sencillo que ingenieros de campo e integradores puedan entender solo con los nombres de los topics.

Cuándo elegir AMQP

Los mensajes son unidades de trabajo que un consumidor debe procesar y confirmar.
Necesitas reglas de enrutamiento sofisticadas, dead-letter queues y políticas por cola.
Todos los productores y consumidores son servicios backend en un centro de datos o en la nube.
Estás integrando sistemas empresariales que ya hablan AMQP 1.0.

Por qué un broker MQTT gestionado suele ser la opción más sencilla

En el lado de los dispositivos, la simplicidad operativa suele ganar. Un broker MQTT gestionado elimina el trabajo de parches, renovación de certificados, escalado del número de conexiones y aislamiento multi-tenant, y deja que tu equipo se centre en el diseño de topics y en los consumidores. ConnectMQ admite MQTT 3.1.1 y 5.0, TLS con un certificado de Let's Encrypt, suscripciones compartidas en el plan Serverless de pago y cuotas por plan con protección contra inundaciones. No incluye un bridge AMQP, así que el bridge sigue siendo un servicio tuyo, exactamente como se muestra arriba. Para comparar opciones de alojamiento de forma más amplia, lee la guía de brokers MQTT en la nube, y para repasar topics y sesiones consulta el tutorial de MQTT. Si estás sopesando colas frente a brokers a nivel conceptual, broker MQTT vs cola de mensajes profundiza en ello.

Empieza con ConnectMQ

Conecta tus dispositivos a ConnectMQ por MQTT y reserva AMQP para los flujos backend en los que mejor rinde. Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, obtén las credenciales generadas y apunta a él tus dispositivos y tu servicio bridge en minutos.

Preguntas frecuentes

¿MQTT es mejor que AMQP para IoT?

Para los dispositivos, normalmente sí: los clientes MQTT son más pequeños, los paquetes más ligeros y el modelo gestiona bien muchas conexiones intermitentes. AMQP encaja mejor en colas de trabajo backend.

¿RabbitMQ puede hablar MQTT?

RabbitMQ ofrece un plugin MQTT que mapea los topics MQTT en su modelo de exchanges. Un broker MQTT dedicado suele darte un soporte más completo de las funciones de MQTT y una operación más sencilla para grandes flotas de dispositivos.

¿MQTT tiene colas como AMQP?

No de forma explícita. El broker mantiene una cola de sesión por cliente para las sesiones persistentes, y las suscripciones compartidas de MQTT 5 permiten que varios consumidores se repartan los mensajes de un topic, lo que cubre muchos casos de uso parecidos a las colas.

¿Puedo usar MQTT y AMQP juntos?

Sí, y es habitual. Los dispositivos publican por MQTT, y un servicio bridge se suscribe y reenvía los mensajes seleccionados a colas AMQP para su procesamiento en el backend.