AppMatic Tech architects IoT platforms that scale from 100 to 100,000 devices, using EMQX or AWS IoT Core MQTT brokers, TimescaleDB or InfluxDB for telemetry, a Kafka or SQS ingestion queue, certificate-based fleet provisioning, and signed over-the-air firmware updates. AppMatic Tech is based in Ahmedabad, India, with 330+ products shipped since 2017.
Why does an IoT platform break between 100 and 100,000 devices?
An IoT platform that connects 100 devices with a monolithic backend and a single MQTT broker functions adequately at low scale. At 100,000 devices, the same architecture produces MQTT broker connection exhaustion, write-heavy database bottlenecks, and API latency spikes that compound under concurrent telemetry load.
The decisions that determine whether a platform can scale, including broker selection, data store choice, connection management, and component independence, must be made before the device fleet grows. Retrofitting them after the fact requires partial or full platform rebuilds.
AppMatic Tech builds IoT platforms with scaling architecture from the first engagement. This article documents the key decisions and their reasoning.
Which MQTT broker should a scaling IoT platform use?
The MQTT broker is the highest-throughput component in any IoT platform. Every device maintains a persistent TCP connection to the broker and publishes telemetry on a defined schedule. At 100,000 devices publishing every 10 seconds, the broker handles 10,000 messages per second at steady state, before accounting for connection churn (devices dropping and reconnecting).
Single-Server Mosquitto: Appropriate for Development and Low Scale
Mosquitto is a lightweight, open-source MQTT broker that runs on a single server. For development environments and deployments under approximately 5,000 devices, Mosquitto is operationally simple and sufficient. It does not support horizontal scaling natively; multiple Mosquitto instances do not form a cluster, so all connections must go to a single node.
EMQX: The Correct Choice for Production Scale
EMQX is an MQTT broker built on the Erlang/OTP platform, the same runtime that powers high-concurrency telecommunications infrastructure. Since version 5.9 in 2025, EMQX ships as a single edition under the Business Source License 1.1, which allows free production use of a single node; running a multi-node cluster requires a license file. A single EMQX node handles 1 million concurrent connections on appropriate hardware. EMQX supports native horizontal clustering: multiple nodes share connection state and route messages between nodes transparently.
AppMatic Tech deploys EMQX for production IoT platforms where the device fleet is expected to grow beyond 10,000 units or where broker high availability is a requirement. EMQX's management API enables programmatic device connection monitoring, topic ACL enforcement, and cluster health visibility.
AWS IoT Core: When the Stack Is Already AWS
AWS IoT Core is a fully managed MQTT broker that scales automatically without cluster management overhead. It integrates natively with AWS Lambda (for serverless message processing), DynamoDB (for device state), and CloudWatch (for broker metrics). Device authentication uses X.509 certificates managed through AWS IoT Fleet Provisioning.
The trade-off is cost: AWS IoT Core pricing is per-message and per-connection rather than infrastructure cost. At very high device counts, a self-managed EMQX cluster can still cost less than AWS IoT Core at equivalent throughput, but the comparison must now include the EMQX cluster license alongside infrastructure cost.
Where should IoT telemetry be stored at scale?
IoT telemetry has a different shape from transactional application data. Telemetry is a continuous stream of timestamped readings, including temperature, location, voltage, and event counts, where queries are almost always time-range based: "show me all readings from device X between 9:00 and 10:00" or "show me all devices reporting above threshold in the last hour."
A standard relational database (MySQL, PostgreSQL) with a naive schema of one row per telemetry event works at low scale and degrades severely at high scale. A table with 500 million rows and unoptimised indexes produces query times measured in seconds on time-range queries that should take milliseconds.
Time-Series Databases
Time-series databases are purpose-built for this data shape. They compress time-stamped data efficiently, maintain write throughput under insert-heavy workloads, and execute time-range queries with ordered index structures designed for the access pattern.
TimescaleDB is a PostgreSQL extension that adds time-series optimisations (hypertables, automatic partitioning by time, continuous aggregates) to a standard PostgreSQL instance. It is the correct choice when the team already operates PostgreSQL, when the relational query capabilities of SQL are needed alongside time-series data, or when migrations from an existing PostgreSQL schema are required.
InfluxDB is a standalone time-series database purpose-built for telemetry and optimised for write throughput. InfluxDB 3 is queried with SQL or InfluxQL; Flux, the query language of InfluxDB 2, is in maintenance mode and is not supported in InfluxDB 3. InfluxDB works well for pure telemetry use cases where the data model is straightforward (measurements, tags, fields, timestamps).
Amazon Timestream is AWS's managed time-series family. Amazon Timestream for LiveAnalytics has been closed to new customers since June 20, 2025, so new AWS-native builds use Amazon Timestream for InfluxDB, which AWS recommends as the alternative, fed from AWS IoT Core through an ingestion service.
Separating Hot and Cold Storage
Telemetry data that is more than 90 days old is rarely queried at full resolution. A cost-effective architecture archives high-resolution telemetry to object storage (S3, GCS) after a defined retention window and maintains only recent data in the time-series database at full resolution. Longer-range queries are served from downsampled aggregates computed on ingestion.
How should IoT backend components scale independently?
A monolithic IoT backend, where the MQTT message handler, device state API, telemetry writer, and user-facing API all run in the same process, cannot scale components independently. If telemetry ingestion throughput spikes, the entire monolith requires scaling, including components that are not under load.
The correct architecture separates each concern into an independently deployable component:
- Message ingestion layer: Consumes from the MQTT broker, validates message format and device identity, and writes to the message queue. Scales based on broker throughput.
- Message queue: Decouples ingestion throughput from storage write throughput. Kafka, RabbitMQ, or AWS SQS/Kinesis depending on scale and managed service preference. The queue absorbs telemetry bursts without propagating back-pressure to the broker.
- Telemetry writer: Consumes from the queue and writes to the time-series database in batched inserts. Scales based on write throughput requirements.
- Device state service: Maintains the last-known state of each device (online/offline, last reading, firmware version). This service has a fundamentally different data access pattern from telemetry storage and should use a different data store (Redis for last-known state, PostgreSQL for device registry).
- User-facing API: Serves the mobile app and web dashboard. Scales based on user request volume, independent of telemetry ingestion load.
This separation ensures that a telemetry storm from a device fleet does not degrade the user-facing API, and that scaling the API layer does not require scaling the ingestion layer.
How are 100,000 IoT devices provisioned securely?
At 100 devices, generating device credentials manually and loading them via USB is feasible. At 100,000 devices, this approach is not possible.
A scalable device provisioning model generates unique device certificates and identities programmatically at manufacturing time, registers them against the device registry before the hardware ships, and activates the device on first network connection. AWS IoT Fleet Provisioning supports this pattern with a claim-based provisioning flow where devices carry a provisional certificate that is exchanged for a permanent certificate on first connection.
For non-AWS stacks, AppMatic Tech implements a provisioning service that issues device certificates signed by a private CA, registers the device in the registry, and delivers the certificate to the device via a one-time HTTPS provisioning endpoint.
How do over-the-air firmware updates work at fleet scale?
An IoT platform at scale must support firmware updates pushed to the device fleet without physical access. OTA update architecture involves: a firmware binary storage layer (S3 or equivalent), a device update service that targets devices by firmware version, group, or individual ID, a differential update mechanism (sending only the changed bytes rather than the full binary), and a device-side update agent that verifies the binary signature before flashing.
Failure handling matters as much as the update itself. A firmware update that bricks a device in the field at 100,000-device scale is a significant operational event. AppMatic Tech implements rollback partitions on device firmware where possible; the device retains the previous firmware version and falls back automatically if the new version fails to boot.
How does AppMatic Tech build scalable IoT platforms?
AppMatic Tech designs and builds IoT platform architectures for device manufacturers and fleet operators. The technical scoping process covers broker selection, data architecture, provisioning model, and OTA strategy. For a connected-device engineering example, see how AppMatic Tech built Trackwel, a BLE-connected nutrition platform with a custom hardware integration layer. For the protocol and device-management decisions behind a scalable fleet, read BLE vs Wi-Fi vs MQTT for IoT integration and MCP server for IoT device management. Contact the team at contact@appmatictech.com to begin the discussion.
Sources
| Claim used in this article | Source |
|---|---|
| EMQX 5.9 and later licensed under BSL 1.1; free single node, license required for clusters | EMQX, adopting the Business Source License |
| Timestream for LiveAnalytics closed to new customers from June 20, 2025; Timestream for InfluxDB recommended | AWS, Timestream for LiveAnalytics availability change |
| InfluxDB 3 queried with SQL and InfluxQL; Flux in maintenance mode | InfluxData, the future of Flux |
Frequently Asked Questions
- At what device count does an IoT platform need EMQX instead of Mosquitto?
- AppMatic Tech starts evaluating EMQX when the fleet is expected to exceed about 5,000 concurrent connections, when broker high availability is required, or when device connections must be managed programmatically. Below those thresholds, a monitored single Mosquitto instance is operationally simpler. High availability means a multi-node EMQX cluster, which requires an EMQX license from version 5.9 onward.
- Is EMQX still open source?
- Not for new releases. From version 5.9, EMQX merged its Community and Enterprise editions into one product under the Business Source License 1.1. The license allows free production use of a single node, while a multi-node cluster requires a license file. Versions released before 5.9 remain under Apache 2.0.
- Which time-series database should an IoT platform use?
- AppMatic Tech recommends TimescaleDB when the team already runs PostgreSQL and needs SQL joins alongside telemetry, and InfluxDB 3 for pure telemetry workloads queried with SQL or InfluxQL. On AWS, new builds use Amazon Timestream for InfluxDB, because Timestream for LiveAnalytics stopped accepting new customers on June 20, 2025.
- Can a MySQL database handle IoT telemetry at 100,000 devices?
- MySQL can, with partitioning by device ID and time range, aggressive indexing, and read replicas. The operational overhead of keeping it performant at that scale is significantly higher than running a time-series database built for the access pattern, so AppMatic Tech recommends TimescaleDB when the team already operates PostgreSQL.
- How does AppMatic Tech handle telemetry from devices on unreliable cellular connections?
- MQTT QoS 1 with persistent sessions delivers messages published before a disconnect once the connection is re-established. For devices with very unreliable connectivity, AppMatic Tech adds a device-side queue that buffers readings locally and transmits them as a batch when connectivity returns.