Modelos de precios de brokers MQTT: cómo estimar tu factura

Los precios de los brokers MQTT resultan confusos sobre todo porque cada proveedor mide algo distinto: uno factura por conexión, otro por mensaje, un tercero por gigabyte y un cuarto por clúster dedicado. Esta guía explica cada modelo de precios, muestra qué cargas de trabajo favorece o penaliza y te da un método repetible para estimar tu propio uso y comparar presupuestos en igualdad de condiciones. A propósito no incluye cifras de precios, porque cambian a menudo; el método sigue siendo válido.

Por qué varían tanto los precios de los brokers MQTT

Los costes reales de un broker proceden de unos pocos recursos: memoria por conexión abierta, CPU por mensaje enrutado, ancho de banda de red, almacenamiento para mensajes retenidos y en cola, y las personas que lo operan. Cada proveedor elige uno o dos de ellos como unidad de facturación y agrupa el resto en los límites del plan. Como resultado, dos servicios pueden parecer baratos o caros para exactamente la misma flota según la forma de tu tráfico.

Piensa en dos flotas. La primera tiene muchos miles de dispositivos que envían cada uno una lectura pequeña cada quince minutos. La segunda tiene unas pocas decenas de máquinas que transmiten datos de alta frecuencia. La primera es intensiva en conexiones y ligera en mensajes; la segunda, lo contrario. Un modelo por conexión favorece a la segunda flota y uno por mensaje favorece a la primera. Conocer la forma de tu tráfico lo es todo.

Los modelos de precios más comunes de los brokers MQTT

1. Por conexión

Pagas por el número de conexiones simultáneas, a menudo medido como pico o como máximo mensual. El volumen de mensajes puede ser ilimitado dentro de un uso razonable o tener un tope por plan.

• Favorece: dispositivos muy habladores, tasas de mensajes altas, flotas pequeñas.
• Penaliza: flotas enormes de dispositivos casi siempre inactivos y arquitecturas en las que cada pestaña del navegador o app móvil mantiene su propia conexión.
• Vigila: si el recuento es simultáneo o acumulado, y si las tormentas breves de reconexiones cuentan para el pico.

2. Por minuto de conexión (tiempo de sesión)

Pagas por el tiempo total que los clientes permanecen conectados, normalmente contado en minutos de conexión o de sesión. Es habitual en plataformas IoT en la nube que facturan todo por consumo.

• Favorece: dispositivos que se conectan brevemente, publican y se desconectan.
• Penaliza: dispositivos siempre conectados, que acumulan cada uno un mes entero de minutos.
• Vigila: cómo se redondean las fracciones de minuto y si el tráfico de keepalive cuenta también como mensajes.

3. Por mensaje

Pagas por mensaje publicado o entregado, a menudo en bloques. Algunos servicios cuentan un mensaje una vez al publicarlo; otros cuentan cada entrega a cada suscriptor, de modo que una publicación con diez suscriptores cuenta como once. Otros cuentan en incrementos de tamaño fijo, así que un payload grande cuenta como varios mensajes.

• Favorece: flotas grandes y poco activas.
• Penaliza: telemetría de alta frecuencia, fan-out a muchos suscriptores y payloads grandes.
• Vigila: si se cuentan los pings, las suscripciones, las entregas de mensajes retenidos y los acuses de QoS.

4. Por volumen de tráfico

Pagas por gigabyte transferido de entrada, de salida o ambos. Es parecido a cómo se factura la red en la nube.

• Favorece: payloads binarios compactos como Sparkplug B o CBOR.
• Penaliza: JSON verboso, fan-out alto y cargas similares a vídeo.
• Vigila: si se incluye la sobrecarga de TLS y del protocolo, y si la entrada y la salida tienen precios distintos.

5. Planes por niveles con cuotas

Pagas un importe fijo por nivel, y cada nivel incluye límites de conexiones, tamaño de mensaje, nivel de QoS, rendimiento o funciones. Es el modelo más predecible a efectos de presupuesto.

• Favorece: equipos que quieren una factura mensual conocida.
• Penaliza: cargas de trabajo que quedan justo por encima del límite de un nivel.
• Vigila: qué ocurre al llegar al límite: rechazo, limitación o facturación automática del exceso.

6. Capacidad dedicada

Pagas por un clúster aislado dimensionado en instancias, nodos o unidades de capacidad, independientemente de cuánto lo uses. BYOC (bring your own cloud) es una variante en la que la infraestructura se ejecuta en tu propia cuenta cloud, de modo que pagas al proveedor cloud por los recursos y al fabricante por la gestión.

• Favorece: cargas grandes y estables, aislamiento estricto y requisitos de residencia de datos.
• Penaliza: cargas pequeñas o con picos que dejan capacidad ociosa.
• Vigila: compromisos mínimos, multiplicadores por alta disponibilidad y quién paga el tráfico entre zonas.

7. Licencias autogestionadas

Para el software que operas tú mismo, los proveedores pueden cobrar por nodo, por núcleo, por tramo de conexiones o mediante un acuerdo empresarial. La licencia es solo una parte del coste; la infraestructura y el tiempo del personal suelen pesar más. Nuestra guía sobre el coste total de propiedad de un broker MQTT cubre esos costes ocultos.

Los modelos de precios de un vistazo

Cómo estimar tu uso

Antes de comparar presupuestos, mide o estima tu carga de trabajo. Cualquier modelo de precios se puede calcular a partir del mismo puñado de cifras:

1. Dispositivos (D): número de clientes que publican.
2. Otros clientes (B): backends, dashboards, sesiones de navegador, instancias de Node-RED.
3. Pico de conexiones simultáneas: normalmente D + B, más margen para el solapamiento de reconexiones.
4. Mensajes por dispositivo y hora (R).
5. Tamaño medio del payload en bytes (S).
6. Media de suscriptores por mensaje (F): fan-out.
7. Fracción de tiempo conectado (C): 1,0 para dispositivos siempre conectados.

A partir de ellas, obtén las cifras mensuales (con 730 horas al mes):

published messages / month  = D x R x 730
delivered messages / month  = published x F
connection-minutes / month  = (D + B) x C x 730 x 60
payload traffic in  (bytes)  = published x S
payload traffic out (bytes)  = delivered x S

Un ejemplo práctico con cifras supuestas: 400 dispositivos que publican cada 30 segundos (R = 120), un payload JSON de 200 bytes y dos suscriptores por mensaje (un proceso que escribe en base de datos y un dashboard).

published  = 400 x 120 x 730          = 35,040,000 messages / month
delivered  = 35,040,000 x 2           = 70,080,000 messages / month
traffic in = 35,040,000 x 200 bytes   = about 7 GB / month
traffic out= 70,080,000 x 200 bytes   = about 14 GB / month
peak connections = 400 + 3 backend clients + headroom

Aplica las unidades de cada proveedor a estas cifras y añade a las estimaciones de tráfico una sobrecarga de protocolo (TLS, cabeceras MQTT, keepalives) de unas cuantas decenas por ciento, en lugar de suponer que los bytes del payload lo son todo. Un piloto en un broker real, observado desde su consola o mediante las estadísticas $SYS, te permite sustituir las suposiciones por valores medidos.

Palancas de coste que controlas

Sea cual sea el modelo, normalmente puedes reducir la factura con decisiones de diseño:

• Publica al cambiar el valor o con bandas muertas en lugar de a intervalos fijos y rápidos.
• Agrupa varias lecturas en un solo mensaje cuando la latencia lo permita.
• Usa payloads compactos o los topic aliases de MQTT 5 para reducir bytes.
• Usa suscripciones compartidas en lugar de muchos consumidores idénticos.
• Evita una conexión al broker por pestaña del navegador cuando un backend puede hacer el fan-out.

Cómo trasladar tu estimación a los planes de ConnectMQ

ConnectMQ usa planes por niveles definidos por límites, lo que simplifica la estimación: busca el plan más pequeño cuyos límites cubran tu pico de conexiones, tu QoS y tu tamaño de mensaje. Serverless (Free) funciona en un clúster compartido con hasta 25 conexiones, QoS hasta 1 y mensajes de 256 KB, lo que encaja con prototipos y pilotos pequeños. Serverless (Paid) lo amplía a hasta 1.000 conexiones, QoS 2, mensajes de 1 MB y suscripciones compartidas. Más allá, Dedicated ofrece un clúster aislado, BYOC se ejecuta en tu propia cuenta cloud gestionada por ConnectMQ y Self Managed Enterprise se ejecuta en tu infraestructura. Cuando se alcanza una cuota, los clientes MQTT 5 reciben un reason code claro como 0x97 (cuota superada), así que los límites nunca fallan en silencio. El artículo sobre cuotas de conexión de un broker MQTT explica cómo planificar en torno a ellas.

Compara los planes de ConnectMQ

Empieza con el plan Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, mide tu tráfico real durante un piloto y sube de plan solo cuando las cifras lo indiquen. ConnectMQ es un broker MQTT gestionado con los mismos endpoints y el mismo código de cliente en todos los planes. Para entender los modelos de despliegue, lee nuestra guía sobre el broker MQTT en la nube, y consulta broker MQTT con plan gratuito para saber qué esperar de los planes gratuitos del mercado.

Preguntas frecuentes

¿Qué modelo de precios de broker MQTT es el más barato?

Ninguno es el más barato en general. El precio por conexión encaja con pocos clientes muy activos, el precio por mensaje con muchos dispositivos poco activos y la capacidad dedicada con cargas grandes y estables. Estima primero tu carga de trabajo y luego aplica cada modelo.

¿Cuentan los pings de keepalive como mensajes?

Depende del proveedor. Algunos cuentan solo las publicaciones de la aplicación y otros cuentan todos los paquetes MQTT. Pregúntalo explícitamente, porque intervalos de keepalive cortos en una flota grande pueden sumar mucho.

¿Cómo evito cargos inesperados por exceso?

Elige un plan cuyos límites rechacen o limiten en lugar de facturar automáticamente, vigila el uso en la consola y configura alertas antes de acercarte a una cuota.

¿Puedo estimar costes sin dispositivos reales?

Sí, con la fórmula de esta guía y tasas y tamaños de payload supuestos. Sustituye las suposiciones por valores medidos en un piloto pequeño en cuanto puedas.