Direct answer

Select an MQTT broker by reproducing your workload, failure modes, security model, and operating constraints. Headline connection counts are not comparable without packet rate, subscription fan-out, session persistence, queue depth, payload size, TLS cost, and recovery behavior. The right broker is the one the team can operate and restore within the product’s service objectives, with acceptable lock-in and a tested exit path.

Scope and non-scope

This guide covers MQTT protocol behavior, connection and session handling, routing, persistence, authorization integration, clustering, observability, and operations. It does not select the complete IoT platform or assume that a broker should provide registry, rules, analytics, and storage. Evaluate those as separate capabilities even when sold together.

Define the workload before the shortlist

Describe steady state and recovery as distributions, not one device count. Record concurrent connections, new connections per second, publishes per second, payload percentiles, QoS mix, subscriptions per client, wildcard fan-out, retained messages, persistent sessions, offline queue limits, and geographic placement. Include TLS handshakes, authentication latency, and authorization lookups.

Model correlated events: mobile-network recovery, certificate-service slowdown, broker node loss, rolling upgrade, or downstream outage. These often stress admission, session restoration, storage, and consumer queues before steady-state routing reaches its limit.

Selection criteria

Protocol correctness comes first. Test the exact versions and features used, including session expiry, message expiry, receive maximum, reason codes, shared subscriptions, retained messages, and wills. Verify behavior at limits and across upgrades.

Understand where session and retained state lives, how it replicates, which failures cause redistribution, and whether the consistency trade-off matches product semantics. “Clustered” does not explain recovery time or what happens to unacknowledged messages.

Security must integrate with the trust chain. Confirm TLS policy, client certificate validation, token support, ACL expressiveness, revocation, secret rotation, administrative authorization, and audit logging. Avoid a synchronous remote authorization call on every packet without a bounded failure policy.

Operations determine long-term cost. Require metrics for connections, authentication failures, inflight messages, queue age, dropped or expired messages, routing rate, storage pressure, and node recovery. Review upgrade procedure, backup scope, capacity controls, incident tooling, support boundaries, and version lifecycle.

Finally score portability. Standard MQTT reduces client lock-in, but proprietary rules, bridge semantics, management APIs, session formats, and monitoring can still make migration expensive.

Evaluation procedure

  1. Write pass/fail requirements separately from weighted preferences.
  2. Build a representative client harness using production SDKs and TLS settings.
  3. Validate protocol semantics before performance tests.
  4. Run steady-state load long enough to expose queue or storage growth.
  5. Inject node loss, partitions, authentication latency, storage pressure, and downstream backlog.
  6. Measure time to stable recovery, not only time until the cluster reports healthy.
  7. Perform an upgrade and rollback with active sessions.
  8. Export configuration, ACLs, metrics, and a sample workload to prove portability.

Do not publish a universal benchmark number. Record hardware, topology, versions, generator, clients, payloads, TLS, session settings, and thresholds so the result is reproducible.

Failure modes

A broker may sustain many idle sockets but collapse under reconnect handshakes. Persistent sessions can make node replacement slow because stored subscriptions and queues must move. A permissive ACL can invalidate an otherwise strong platform. Disk-backed queues can protect messages while exhausting storage during downstream failure. Autoscaling can add routing capacity yet amplify state redistribution. Managed services can reduce maintenance while limiting network placement, extensions, or incident visibility.

Implementation checklist

  • Workload and recovery distributions are documented.
  • Protocol and security requirements have pass/fail tests.
  • Persistent state ownership and recovery are understood.
  • Tests use production clients, TLS, authentication, and payload sizes.
  • Failure tests measure stable recovery and lost or duplicated outcomes.
  • Queue, storage, and admission limits are explicit.
  • Upgrade, rollback, backup, and support procedures are exercised.
  • Proprietary dependencies and migration costs are recorded.

Decision record

The final recommendation should preserve the rejected alternatives and evidence, not just a score. Record workload assumptions, hard failures, operational strengths, commercial constraints, and which claims remain unverified. Identify who owns upgrades, capacity, security response, and 24-hour incidents under both managed and self-hosted options. Revisit the decision when fleet shape, geographic placement, persistence requirements, or team capability changes. A benchmark is not permanent product truth. Keeping the harness and acceptance thresholds runnable is more valuable than keeping a polished comparison spreadsheet whose inputs no longer match production.

Ownership questions

Before signing off, name the team that will tune client admission, investigate session corruption, rotate broker credentials, approve upgrades, and communicate protocol incidents. For a managed service, identify which metrics and artifacts the provider exposes and which failures remain the customer’s responsibility. For self-hosting, include on-call staffing, security patches, capacity procurement, and disaster recovery rather than comparing license cost alone.

Require a support exercise using a deliberately ambiguous fault. Measure whether engineers can move from a device symptom to connection, authentication, session, routing, and downstream evidence without privileged vendor intervention. Review data residency, maintenance windows, service quotas, and export formats. The best benchmark performer can still be the wrong production choice when its failure boundary or support model conflicts with the organization operating it.

Primary sources

Use the OASIS MQTT 5.0 specification for protocol acceptance and NISTIR 8259A when mapping device cybersecurity capabilities to platform services. Broker architecture, persistence, clustering, and operational claims must be verified in each candidate’s official documentation and reproduced in the target environment.