Skip to content
Stand with Ukraine flag

Deployment Scenarios

Choosing the right deployment architecture depends on your device count, message throughput, high-availability requirements, and operational complexity budget. This page walks through common scenarios with sizing guidance.

Start by characterizing your workload. Two representative examples:

Parameter20K GPS trackers100K smart meters
Devices20,000100,000
Messages per device1 per 10 sec1 per 15 min
Messages per second2,000~111
Data points per message5 (lat, lon, speed, fuel, status)3 (energy, voltage, current)
Data points per second10,000~333
Daily writes~864M~28.8M
Daily disk (PostgreSQL)~130 GB~4.3 GB
Daily disk (Cassandra)~26 GB~0.9 GB
FactorWhat it affectsScaling lever
Messages per secondCPU, networkMore Transport pods, more Rule Engine threads
Concurrent connectionsRAMMore Transport pods (each MQTT connection ≈65 KB)
Rule engine complexityCPUMore TB Node replicas
Data points per secondDisk IOPS, CPUDatabase scaling (Cassandra nodes, TimescaleDB partitions)
Dashboard subscriptionsRAM, WebSocket connectionsMore TB Node replicas

A single server running ThingsBoard in monolithic mode with PostgreSQL on the same machine.

AttributeValue
Max devices~300,000 (depending on message rate)
Max data points/sec~5,000 (PostgreSQL limit)
High availabilityNo — single point of failure
Recommended RAM4–16 GB
AdvantagesLimitations
Simplest deployment — one machine, one processNo redundancy — downtime during maintenance or failure
Lowest operational costPostgreSQL write throughput ceiling
No Kafka, Redis, or Zookeeper requiredCannot scale individual components

Best for: development, testing, demos, and small production deployments with moderate message rates.

Scenario B: Standalone Monolith + External Database

Section titled “Scenario B: Standalone Monolith + External Database”

ThingsBoard on one server, database on a separate managed service (AWS RDS, Azure Database, Google Cloud SQL).

AdvantagesLimitations
Automated database backups and failoverStill a single ThingsBoard process — no HA for the application
Can use managed Cassandra for higher write throughputNetwork latency between server and DB
Easier to scale storage independentlyMore infrastructure to manage than Scenario A

Best for: production deployments that need reliable database operations but can tolerate brief ThingsBoard restarts.

ThingsBoard deployed as microservices on Kubernetes or Docker Swarm with separate transport, node, and database pods.

Smart meters reporting every 15 minutes — moderate message rate, large device count.

ComponentInstancesSpecs (per instance)
MQTT Transport22 CPU, 4 GB RAM
TB Node24 CPU, 8 GB RAM
Zookeeper31 CPU, 1 GB RAM
Redis12 CPU, 4 GB RAM
Kafka32 CPU, 4 GB RAM
PostgreSQL14 CPU, 16 GB RAM, SSD

GPS trackers reporting every 10 seconds — high message rate, high write throughput.

ComponentInstancesSpecs (per instance)
MQTT Transport82 CPU, 4 GB RAM
TB Node154 CPU, 8 GB RAM
JS Executor201 CPU, 1 GB RAM
Cassandra158 CPU, 16 GB RAM, NVMe SSD
Zookeeper31 CPU, 1 GB RAM
Redis3 (Sentinel)2 CPU, 4 GB RAM
Kafka34 CPU, 8 GB RAM, SSD
PostgreSQL14 CPU, 16 GB RAM, SSD

For benchmark results that validate these sizing recommendations, see Performance.