ThingsBoard Alternative: FastBee Migration Guide
If your team is evaluating self-hosted IoT platforms beyond ThingsBoard, FastBee deserves a place on the POC shortlist. It puts device management, Thing Models, rule scripts, Scene Linkage, visualization, and mobile apps on one coherent product path. The open-source edition embeds an MQTT Broker and deploys with Docker Compose, while the Commercial and Cluster editions use perpetual licenses with corresponding source code delivery. For teams working in Java and Vue who need to deliver small and midsize commercial projects on-premises, this is a manageable route.
At the same time, ThingsBoard remains mature in its rule-chain ecosystem, native LwM2M/CoAP support, microservices-based horizontal scaling, and global community. There is no universal winner independent of project constraints. This article provides verifiable facts and a decision method rather than a verdict.
1. Scope and Evidence Boundaries
This article was written on October 31, 2026. Factual statements are based on ThingsBoard's official documentation, the official GitHub repository README and LICENSE text, and FastBee's official documentation and public licensing page. Sources are listed at the end.
This is not a uniform benchmark. The capacity guidance in ThingsBoard's official documentation and the benchmark report published by FastBee were produced on different hardware, Brokers, message sizes, QoS levels, and persistence policies. Their numbers cannot be converted or ranked against each other. Connection counts, TPS, end-to-end latency, and recovery time must be measured again under identical conditions during your project POC.
This article separates two kinds of statements:
- Verifiable facts: license texts, published technology stacks, officially listed capabilities, and delivery methods, with sources.
- Selection recommendations: judgments based on team skills, project scale, commercial delivery, and operational constraints. These are not third-party laboratory findings.
2. Executive Summary: Fit by Scenario
| Scenario | Recommendation |
|---|---|
| Java + Vue team delivering self-hosted small or midsize commercial projects, needing licensed source and a clear one-time purchase | Evaluate FastBee Commercial first |
| Projects in China needing GB/T 28181 video, industrial protocols such as Modbus/JT808, and WeChat mini program or mobile apps | Evaluate FastBee Commercial first |
| Native LwM2M/CoAP/SNMP transports, a mature rule-chain and widget ecosystem, and global community resources | Stay with ThingsBoard |
| Platform-engineering teams needing microservices, very large device fleets, and independently scalable transport layers | Stay with ThingsBoard (microservices architecture) |
| Small commercial production within the official Additional Use Grant, willing to keep brand attribution | Evaluate the free production allowance of ThingsBoard 4.4+ against the official terms |
| Large fleets of legacy industrial devices connected through gateways | Both platforms take a gateway path: ThingsBoard IoT Gateway or FastBee protocol practice; POC each |
The "Recommendation" column is a selection judgment, not a feature or performance ranking. Commercial terms on both sides should be reviewed against the original texts by your legal or procurement owner.
3. Licensing and Commercial Use Boundaries
License terms determine whether a platform can legally serve your project, so confirm them before comparing features.
ThingsBoard's license changed at version 4.4. The official GitHub README states that starting with 4.4 the platform adopts the Business Source License 1.1 (BUSL, source-available rather than an OSI-defined open-source license): you may read, build, modify, fork, and redistribute the code, and use it freely for development and testing. Production use is free within the Additional Use Grant; beyond it, or to remove ThingsBoard branding, a commercial license is required. Each release converts to Apache 2.0 four years after it ships, and versions before 4.4 remain Apache 2.0. Key points of the Additional Use Grant in the LICENSE text: production use at no charge requires either non-commercial use with no more than 1,000 devices across the organization, or commercial use with no more than 100 devices on a single server; the "Powered by ThingsBoard" attribution in the UI must remain visible and unmodified; production use requires a valid no-charge license key issued by ThingsBoard, and the key functionality must not be bypassed. The official pricing page bills cloud and professional offerings by device count and related dimensions, with white labeling appearing at higher tiers.
FastBee's edition boundaries are published on its Commercial License page: the open-source edition uses AGPL 3.0 and is limited to non-commercial use. The Commercial and Cluster editions are perpetual licenses validated by an installation certificate; licensed users receive the corresponding source code through a private Git service with one year of source updates included, and may not directly sell or distribute the commercial source code. The open-source edition has no device-count clause, but AGPL's copyleft obligations and the non-commercial restriction mean commercial delivery requires a licensed edition.
The implication for decisions: neither ecosystem is "free for serious commercial production." They differ in how they charge (device/server counts versus a flat perpetual license), in copyleft obligations (AGPL versus BUSL/Apache), and in attribution requirements. Do not base procurement on old prices or old license states reposted by third parties.
4. Architecture and Operational Boundaries
| Dimension | FastBee | ThingsBoard |
|---|---|---|
| Primary stack | Spring Boot + MyBatis + Vue with frontend-backend separation, UniApp mobile apps | Java (Spring); the Web UI is an Angular application |
| Minimal deployment | Open-source edition: single-node Docker Compose one-click deployment with an embedded Netty MQTT Broker, no separate Broker required | Monolithic mode: a single Java process, officially recommended at 2–4 GB RAM; a single node needs only PostgreSQL |
| Storage | MySQL + Redis by default; time-series data optionally on TDengine, IoTDB, or InfluxDB | PostgreSQL always required (entities); time-series on either SQL (PostgreSQL) or Hybrid (Cassandra) |
| Cluster form | Cluster Edition: FMQ service cluster + web cluster, with Kafka and load balancing | Monolithic cluster requires Zookeeper + Kafka + a load balancer; microservices mode scales services independently |
| Official capacity references | The Commercial Edition benchmark is published for its test environment | Official documentation guidance: 50–100K devices at typical reporting rates in monolithic mode; SQL storage ≤5–10K data points/sec, Hybrid (Cassandra) about 1M data points/sec |
Operational boundaries are real costs. At scale, ThingsBoard requires operating Kafka, Zookeeper, optionally Cassandra, and multiple service processes — a higher platform-engineering threshold in exchange for independently scalable services. FastBee runs fewer components, so a small team can operate single-node and midsize deployments, while large-scale horizontal expansion depends on the Cluster Edition and must be validated with benchmarks in your own environment. The official numbers from both sides were produced under different conditions; treat them as references for their own architectures, never divide one by the other to infer a multiplier.
5. Device Access and Protocols
ThingsBoard provides built-in MQTT, HTTP, CoAP, LwM2M, and SNMP transport services, with device credentials supporting Access Token, MQTT Basic, and X.509 certificates. Legacy industrial protocols such as Modbus connect through the separate ThingsBoard IoT Gateway component via connectors — the gateway is an additional deployment unit.
The FastBee open-source edition focuses on its embedded MQTT Broker (TCP 1883 + WebSocket 8083) and GB/T 28181 live video. Device authentication uses a clientId/userName/password model (device number, product ID, and device secret; see MQTT Access). The Commercial Edition adds TCP, UDP, CoAP, HTTP, Modbus, JT808, and other protocols; exact boundaries follow the feature matrix on the license page. For gateways and register mapping of legacy industrial devices, see the protocol practice documentation.
Whichever platform you choose, validate with three representative devices: one standard MQTT device, one existing industrial device, and one field device on an unstable network — covering registration, uplink/downlink, reconnection, and diagnostic logs. A simulator publishing data successfully does not prove field readiness.
6. Rule Engines and Visualization
ThingsBoard centers on the Rule Chain: a node graph that orchestrates filtering, transformation, alarms, and external integrations, with script nodes executed in an isolated JS Executor sandbox. Combined with the Angular dashboard widget library, the alarm system, and the "Tenant → Customer → Devices & Assets" hierarchy, it offers a mature ecosystem with substantial room for configuration.
FastBee provides rule scripts based on Groovy (Java-syntax), Scene Linkage, and a visual rule designer (a Commercial Edition capability). Its alert center connects to notification channels common in China such as SMS, voice calls, DingTalk, and WeCom, and it adds visualization dashboards, reports, and an optional Web SCADA module. These capabilities share one product context with devices, products, and industry applications, which reduces integration work.
A key caveat: the two rule models do not map one-to-one. A ThingsBoard rule chain cannot be imported into FastBee; migration means re-implementing business logic with rule scripts and Scene Linkage. Measuring that effort is exactly what a POC is for.
7. Migration Findings: Concept Mapping and Gaps
The conclusion first: there is no automated migration tool from ThingsBoard to FastBee. Plan migration as "concept mapping + business re-implementation + data relocation," not as a one-click conversion.
| ThingsBoard concept | FastBee counterpart | Migration approach |
|---|---|---|
| Device Profile | Product + Thing Model | Rebuild property, function (service), and event definitions as a Thing Model |
| Telemetry key/value | Thing Model properties and events | Change reporting payloads to the Thing Model protocol format |
| Access Token device credentials | Device number + product ID + MQTT authentication parameters | Re-issue and distribute credentials according to the MQTT access model |
| Rule Chain | Rule Script / Scene Linkage | Inventory each chain and re-implement; no import path |
| Dashboard / Widget | Visualization dashboards / reports / Web SCADA (optional module) | Rebuild from a page inventory |
| Tenant / Customer hierarchy | Multi-tenancy and data permissions (Commercial Edition) | Redesign the tenant and permission model |
| ThingsBoard Edge | Edge scenarios need separate evaluation | POC against FastBee's gateway documentation and actual project needs |
Main gaps and risks: historical telemetry must be exported through the ThingsBoard REST API, transformed to the Thing Model, written to the new platform, and sample-verified. External system integrations inside rule chains (Kafka forwarding, REST calls, and so on) need equivalent implementations on the FastBee side through data bridging or rule scripts, plus regression testing. A parallel run of the old and new platforms is usually required as a grace period during migration. Before deciding, pin down the ThingsBoard version you currently run and its license terms — obligations differ before and after 4.4.
8. Recommended Two-Week POC Checklist
| Item | Minimum acceptance criterion | Required evidence |
|---|---|---|
| License and source | The target edition's license permits the intended use; source and third-party boundaries are documented | License matrix, license text, repository access record |
| Real devices | Three representative devices complete registration, uplink/downlink, reconnection, and diagnostics | Device list, packet captures, operation log |
| Business loop | Reporting triggers a rule, raises an alert, notifies an owner, executes control, and leaves a history trace | Rule configuration, alert records, screenshots |
| Migration effort | One real rule chain is equivalently re-implemented and regression-tested on the target platform | Implementation record and work hours |
| Security | Authentication, privilege escalation, Topic/API permissions, secrets management, and upgrade flow all checked | Test cases and remediation record |
| Performance | Stable connections and throughput meet project targets on identical hardware and message models | Raw benchmark scripts, monitoring, results |
| Failure recovery | Network loss, restarts, and node failures are diagnosable and recover without unacceptable data loss | Fault-injection record |
| Operations | Actual operators independently complete backup, restore, logs, monitoring, upgrade, and rollback | Runbook and exercise record |
9. Official Sources and Further Reading
These sources support the factual statements in this article and were checked on October 31, 2026:
- ThingsBoard: official GitHub repository (README license statement), LICENSE text (BUSL 1.1 with Additional Use Grant), architecture reference, monolithic deployment reference, official pricing page, IoT Gateway documentation, and the Modbus connector configuration.
- FastBee: Commercial License and feature matrix, open-source edition overview, Commercial platform introduction, Cluster documentation, MQTT Access, and industry cases.
- Further reading: 2026 Open-Source IoT: FastBee, JetLinks, DGIOT.
10. FAQ
10.1. Can FastBee fully replace ThingsBoard?
There is no universal "full replacement." FastBee fits Java + Vue teams delivering self-hosted small and midsize commercial projects, with perpetual licenses and corresponding source code. ThingsBoard remains mature in its rule-chain ecosystem, native LwM2M/CoAP access, and microservices-based horizontal scaling. Validate both under identical conditions with the POC checklist in this article before deciding.
10.2. Is ThingsBoard still Apache 2.0 after version 4.4?
No. The official README and LICENSE text state that 4.4 onward uses BUSL 1.1: development and testing are free; production use is free within the Additional Use Grant (non-commercial use with up to 1,000 devices, or commercial use with up to 100 devices on a single server, keeping brand attribution and holding an official license key); each release converts to Apache 2.0 four years after it ships. Versions before 4.4 remain Apache 2.0. Review the official license text before any commercial use.
10.3. Can ThingsBoard rule chains be imported directly into FastBee?
No. The rule models differ: rule chains must be inventoried per business flow and re-implemented on the FastBee side with Groovy rule scripts or Scene Linkage. Including "equivalent re-implementation of one real rule chain" as a POC acceptance item directly measures the migration effort.
10.4. What is the most critical POC acceptance item for migration?
Real device access plus the complete business loop: reporting, rules, alerts, notifications, control, and historical data must all pass end to end. Identical-environment benchmarking and fault injection come next. Verifying only that pages load and a simulator can publish is not enough to support a migration decision.