Alternative à HiveMQ Cloud : une grille équitable pour comparer les brokers MQTT managés

Si vous cherchez une alternative à HiveMQ Cloud, l'outil le plus utile est une méthode équitable et reproductible pour comparer les brokers MQTT managés. Cet article vous la fournit : les critères qui comptent, la façon de tester chacun vous-même et la position de ConnectMQ sur chaque point, pour que vous décidiez à partir de vos exigences plutôt que de pages marketing.

HiveMQ en contexte

HiveMQ est l'un des noms les plus connus du monde MQTT. L'entreprise propose un broker d'entreprise et un service cloud managé, et elle a publié des contenus pédagogiques très lus sur le protocole. De nombreux ingénieurs ont découvert MQTT grâce à ces ressources. Chercher une alternative ne signifie pas que HiveMQ pose problème ; les équipes comparent les fournisseurs pour de nombreuses raisons : adéquation du modèle tarifaire, options de déploiement, localisation des données, fonctionnalités industrielles ou simple diligence avant un contrat de longue durée.

Les plans, limites et fonctionnalités de tous les services managés évoluent dans le temps. Considérez toute comparaison, y compris celle-ci, comme un point de départ, et consultez la documentation et les conditions actuelles de chaque éditeur avant de décider.

La grille de comparaison

Notez chaque fournisseur selon les mêmes critères. La colonne de droite présente nos propres capacités documentées, pour vous donner un point de référence concret.

Remarquez la ligne des intégrations. Certains fournisseurs incluent des connecteurs de données natifs ou des extensions ; notre broker reste volontairement léger et vous laisse intégrer via des clients MQTT standard. Que ce soit un atout ou une lacune dépend de si vous utilisez déjà des outils comme Node-RED ou un pipeline de séries temporelles.

Les critères en détail

Complétude du protocole

MQTT 3.1.1 et MQTT 5.0 doivent tous deux être pris en charge. Si vous comptez utiliser des fonctionnalités MQTT 5 comme les abonnements partagés, l'expiration des messages, les alias de topic ou les response topics, vérifiez chacune explicitement sur le plan que vous achèteriez, et pas seulement la mention « MQTT 5 pris en charge ». L'article sur les fonctionnalités de MQTT 5 explique lesquelles comptent pour quels cas d'usage.

Offre gratuite et paliers de plans

Une offre gratuite n'a de valeur que si elle permet de tester avec de vrais appareils et un vrai TLS. Regardez le nombre de connexions, la QoS maximale et la taille des messages, et vérifiez si vous pouvez monter en gamme sans changer de nom d'hôte ni d'identifiants. Le guide sur l'offre gratuite d'un broker MQTT liste les points à examiner.

Adéquation du modèle tarifaire

Les fournisseurs facturent selon les connexions, les messages, le trafic, la taille du cluster ou une combinaison. Aucun de ces modèles n'est meilleur en soi ; ce qui compte, c'est la façon dont votre charge évolue. Une flotte de nombreux capteurs peu bavards se comporte très différemment de quelques machines très bavardes. Modélisez vos connexions et votre débit de messages attendus pour l'année à venir, puis chiffrez chaque fournisseur sur ce profil à partir de ses tarifs publiés actuels.

Gestion industrielle et Sparkplug

Si vous travaillez dans l'industrie, vérifiez comment un broker traite les payloads Sparkplug B. Un broker relaie de toute façon les octets Protobuf, mais un outillage qui les décode et les affiche fait gagner beaucoup de temps de débogage. ConnectMQ décode Sparkplug B (Protobuf ou JSON) et peut le republier dans des topics ISA-95, par exemple de spBv1.0/factory1/DDATA/line1/cnc1 vers connectmq/factory1/production/line1/cnc1/telemetry. Voir MQTT Sparkplug B et Unified Namespace pour le contexte.

Exploitation et visibilité

L'exploitation au quotidien compte davantage que le parcours d'inscription. Demandez-vous comment vous verrez quels clients sont connectés, quels topics sont actifs et à quoi ressemblent les payloads lorsqu'un appareil se comporte mal. Un client web intégré et un navigateur de topics en direct peuvent remplacer beaucoup d'outillage improvisé pendant le débogage. Vérifiez si l'état des connexions est exposé d'une manière exploitable par votre propre supervision ; sur notre broker, par exemple, l'état d'un client est publié sur $SYS/broker/connection/{clientId}/state. Enfin, regardez comment le service se protège, et vous protège, des clients défaillants : quotas, protection contre l'inondation de messages et blocage des échecs de connexion répétés réduisent tous l'impact d'une version de firmware boguée.

Modèle de déploiement

Les clusters serverless mutualisés sont rapides et peu coûteux pour démarrer. Les projets plus importants ou réglementés peuvent nécessiter un cluster dédié isolé, un déploiement dans leur propre compte cloud ou une option auto-gérée. Vérifiez lesquelles de ces options chaque fournisseur propose et, surtout, si vous pouvez passer de l'une à l'autre sans modifier la configuration des appareils.

Portabilité

La meilleure protection contre une mauvaise décision est la possibilité de la changer. Privilégiez les fournisseurs qui vous permettent d'utiliser des clients MQTT standard avec des fonctionnalités standard, afin qu'un changement ultérieur ne touche que les paramètres de connexion.

Testez n'importe quel broker avec le même script

Exécutez un test identique sur chaque candidat. Ce script MQTT.js v5 se connecte en MQTT 5, s'abonne, publie en QoS 1, mesure le temps d'aller-retour et affiche le reason code du serveur en cas d'échec :

// npm install mqtt
const mqtt = require("mqtt");

const url = process.env.MQTT_URL || "mqtts://broker.connectmq.com:8883";
const topic = process.env.MQTT_TOPIC || "connectmq/demo/a91c/rtt";

const client = mqtt.connect(url, {
  clientId: process.env.MQTT_CLIENT_ID || "eval-a91c-js",
  username: process.env.MQTT_USERNAME,
  password: process.env.MQTT_PASSWORD,
  protocolVersion: 5,
  connectTimeout: 10_000,
});

let sentAt = 0;
let count = 0;

client.on("connect", () => {
  console.log("Connected to", url);
  client.subscribe(topic, { qos: 1 }, (err) => {
    if (err) return console.error("Subscribe failed:", err.message);
    sendNext();
  });
});

function sendNext() {
  sentAt = Date.now();
  client.publish(topic, JSON.stringify({ n: count, t: sentAt }), { qos: 1 });
}

client.on("message", (_topic, payload) => {
  const rtt = Date.now() - sentAt;
  console.log(`Message ${count} round trip: ${rtt} ms`);
  count += 1;
  if (count < 10) setTimeout(sendNext, 500);
  else client.end();
});

client.on("error", (err) => {
  console.error("Error:", err.message, err.code ?? "");
  client.end();
});

Exécutez-le d'abord sur le serveur MQTT public gratuit, réservé aux tests et aux données factices, puis sur l'endpoint privé de chaque fournisseur en ne changeant que les variables d'environnement :

node rtt.js
MQTT_URL=mqtts://broker.connectmq.com:8883 MQTT_USERNAME=YOUR_USERNAME \
MQTT_PASSWORD=YOUR_PASSWORD MQTT_CLIENT_ID=YOUR_CLIENT_ID \
MQTT_TOPIC=eval/rtt node rtt.js

Lancez le test depuis l'endroit où se trouvent réellement vos appareils. La latence mesurée depuis votre bureau en dit peu sur celle d'un site distant.

Une liste de notation

1. Listez vos exigences indispensables (par exemple QoS 2, décodage Sparkplug, cluster dédié).
2. Éliminez tout fournisseur qui ne remplit pas une exigence indispensable d'après sa documentation actuelle.
3. Exécutez le script de test sur les fournisseurs restants depuis les emplacements de vos appareils.
4. Connectez un vrai appareil ou une vraie passerelle pendant au moins une journée et surveillez les déconnexions.
5. Vérifiez l'outillage d'exploitation : voyez-vous les topics en direct et l'état des connexions sans logiciel supplémentaire ?
6. Chiffrez votre charge sur un an avec la grille tarifaire actuelle de chaque fournisseur.
7. Confirmez la porte de sortie : pouvez-vous déplacer les appareils en changeant simplement l'hôte, le port et les identifiants ?

Utilisez un broker gratuit comme point de référence

Comme le plan gratuit de ConnectMQ ne demande pas de carte bancaire, il constitue une base de comparaison facile. Créez un broker Serverless gratuit, exécutez le script ci-dessus et explorez vos topics dans le portail. Pour comprendre le paysage plus large, lisez notre panorama des brokers MQTT cloud, la comparaison associée sur l'alternative à EMQX Cloud et l'explication de ce qu'est un broker MQTT managé. Les détails du produit sont sur connectmq.com.

Questions fréquentes

ConnectMQ est-il compatible avec des clients écrits pour HiveMQ Cloud ?

Les clients qui utilisent MQTT 3.1.1 ou 5.0 standard fonctionnent avec n'importe quel broker conforme. En général, seuls l'hôte, le port, les identifiants et le client ID changent.

Comment comparer les tarifs des fournisseurs MQTT managés ?

Modélisez vos connexions et votre volume de messages attendus pour l'année à venir, puis appliquez les tarifs publiés actuels de chaque fournisseur. Les modèles tarifaires diffèrent : comparez le coût total pour votre charge plutôt que les prix d'appel.

ConnectMQ inclut-il des intégrations de données comme des connecteurs de base de données ?

Non. Le broker reste centré sur MQTT ; vous intégrez des outils comme Node-RED, Telegraf ou vos propres abonnés, qui se connectent en tant que clients MQTT.

Où vérifier les fonctionnalités actuelles de HiveMQ Cloud ?

Consultez la documentation officielle et les pages tarifaires de HiveMQ, car les plans et les limites évoluent avec le temps.