ThingsBoard’s own minimum is 1 vCPU and 1GB RAM for evaluation only; a genuinely usable production deployment needs at least 2 vCPU and 4GB RAM, with both CPU and RAM requirements scaling primarily with device count, telemetry frequency and dashboard complexity rather than any single factor alone. Storage, driven by PostgreSQL’s telemetry table growth, is usually the first thing to need attention as a deployment matures, well before CPU or RAM become the binding constraint.
Why this is a separate guide from the setup walkthrough
ThingsBoard Self-Hosted: Complete VPS Setup Guide covers getting ThingsBoard running. This guide covers a different, equally important question: how big a VPS does it actually need, today and as a deployment grows, since under-sizing leads to a sluggish, frustrating platform and over-sizing wastes money on capacity that will sit unused for years.
ThingsBoard’s official minimums, and why they’re a starting point, not a target
ThingsBoard’s own documentation states 1 vCPU and 1GB RAM as a minimum, but this is explicitly an evaluation-only figure, enough to install ThingsBoard and click through its interface, not enough to run it with real devices reporting telemetry continuously. Treat the official minimum as proof the software runs, not as sizing guidance for an actual deployment.
A practical sizing table by device count
| Device count | vCPU | RAM | Notes |
|---|---|---|---|
| Up to 50 devices | 2 | 4GB | Comfortable for typical telemetry intervals (every few minutes to every minute) |
| 50-500 devices | 4 | 8GB | The range most projects on this site’s industrial and business guides actually fall into |
| 500-2,000 devices | 4-8 | 16GB | PostgreSQL tuning and storage planning become genuinely important here, not optional |
| 2,000+ devices | 8+ | 32GB+ | Worth considering splitting ThingsBoard and PostgreSQL onto separate VPS instances, covered below |
These figures assume typical telemetry intervals and dashboard usage consistent with the kind of deployments covered throughout this site, not high-frequency industrial data acquisition at sub-second intervals, which scales the requirements upward considerably faster than device count alone would suggest.
What actually drives resource usage, beyond raw device count
- Telemetry frequency. 500 devices reporting once an hour is a dramatically lighter load than 50 devices reporting every second; frequency, not device count alone, is often the bigger driver.
- Rule chain complexity. ThingsBoard’s rule engine, processing every incoming message against configured logic, scales CPU usage with how much processing each message triggers, not just how many messages arrive.
- Dashboard complexity and concurrent viewers. A dashboard with many widgets, viewed by several people simultaneously, places real load on ThingsBoard’s query layer, separate from the device-ingestion load entirely.
- Telemetry retention. How long historical data is kept directly drives PostgreSQL’s storage growth, the resource most likely to need attention before CPU or RAM do.
PostgreSQL: the part that grows fastest and quietest
ThingsBoard’s PostgreSQL database, storing every telemetry point, grows continuously and, unlike CPU or RAM pressure which shows up as visible slowness, storage exhaustion can happen quietly until the disk is suddenly full and writes start failing. ThingsBoard supports both PostgreSQL alone and a PostgreSQL-plus-Cassandra combination for genuinely high-volume telemetry; for the scale most readers of this site operate at, PostgreSQL alone, with sensible retention policies configured, is entirely sufficient and considerably simpler to operate than adding Cassandra into the mix.
A practical retention discipline, similar to the approach covered in Grafana + InfluxDB on a VPS: decide deliberately how long full-resolution telemetry needs to be kept, and configure ThingsBoard’s TTL (time-to-live) settings accordingly, rather than allowing the database to grow unbounded by default.
Signs it’s time to size up
- Dashboard load times noticeably increasing, particularly for date-range queries spanning weeks or months.
- Rule chain processing visibly lagging behind incoming telemetry, observable in ThingsBoard’s own monitoring views.
- Disk usage approaching capacity, the clearest, most urgent signal, worth monitoring proactively rather than reactively.
Vertically resizing a VPS, the straightforward first response, is covered in VPS for IoT: The Complete Guide‘s discussion of growth signals, usually the right first move before considering anything more architecturally involved.
When to split ThingsBoard and PostgreSQL onto separate VPS instances
For deployments genuinely pushing past the upper end of the sizing table above, separating ThingsBoard’s application layer from PostgreSQL’s database layer onto two VPS instances, communicating over a private network, lets each scale independently rather than competing for the same CPU and RAM. This is a meaningfully bigger architectural step than simply resizing a single VPS, worth doing deliberately once genuinely needed rather than as a default starting configuration.
Where the ThingsBoard affiliate fits
For deployments that have genuinely outgrown what makes sense to self-host, or where a team would rather not own PostgreSQL sizing and tuning at all, ThingsBoard’s managed cloud offering removes this entire question, worth comparing against the self-hosted total cost of ownership at your specific scale before deciding either way.
Frequently asked questions
Does ThingsBoard Professional Edition have different sizing requirements than Community Edition?
The core resource scaling principles are similar, though Professional Edition’s additional features (more advanced rule engine capabilities, for example) can add some overhead. This guide focuses on Community Edition, the self-hosted option covered throughout this site.
How do I actually measure whether my current VPS is undersized, rather than guessing?
ThingsBoard exposes its own internal metrics, and standard Linux tools (htop, df -h) covered throughout this site’s other guides show CPU, RAM and disk pressure directly, worth checking these periodically rather than waiting for a user-visible slowdown to investigate.
Is SSD storage required, or does HDD work for ThingsBoard?
NVMe or SSD storage is strongly recommended, not just for raw speed but because PostgreSQL’s query performance, particularly for historical dashboard queries, depends heavily on disk I/O speed, one of the criteria covered in this site’s VPS provider-selection guide for exactly this reason.
Can I start small and resize later without losing data?
Yes, vertical resizing on any of the providers covered in this site’s buying guides is typically a quick operation that preserves the existing disk and data, making “start appropriately sized for today, resize later as needed” a reasonable default strategy rather than over-provisioning from day one.
Does running ThingsBoard alongside other services (MQTT, Node-RED) on the same VPS change these sizing figures?
Yes, the sizing table above assumes ThingsBoard as the primary workload; running it alongside other services from this site’s guides means adding their resource requirements on top, covered in the Docker guide’s discussion of sizing for multiple co-located services.
JVM memory tuning: a detail worth knowing about
ThingsBoard runs on the Java Virtual Machine, which means its memory behaviour isn’t quite as simple as “however much RAM the VPS has, ThingsBoard will use sensibly”. The JVM’s heap size, how much memory it’s permitted to use, needs configuring explicitly via the JAVA_OPTS environment variable or ThingsBoard’s own configuration file, rather than relying entirely on defaults that may not suit your specific VPS size. Under-allocating heap memory on a otherwise adequately sized VPS is a genuinely common cause of sluggish performance that looks, at first glance, like the VPS itself is undersized when the real issue is JVM configuration not making proper use of the RAM that’s actually available.
A practical monitoring routine worth establishing
Beyond reacting to visible slowness, a simple periodic check, perhaps monthly, of disk usage (df -h), memory pressure (free -h), and CPU load (htop or top) catches the gradual growth pattern typical of a maturing ThingsBoard deployment well before it becomes a user-visible problem. This costs a few minutes and is worth building into a routine rather than treating VPS health as something to only check when something’s already gone wrong.
Comparing self-hosted sizing cost against ThingsBoard’s managed cloud tiers
It’s worth running the comparison covered conceptually in Self-Hosted vs Managed IoT Platforms specifically against ThingsBoard’s own numbers: a self-hosted VPS at the 500-device tier from the sizing table above typically costs a small fraction of what ThingsBoard’s equivalent managed cloud tier charges monthly, the trade being that you own the sizing, tuning and maintenance responsibility this guide covers, rather than ThingsBoard’s team handling it as part of the subscription.
What happens if a device burst (many devices reporting simultaneously) hits an undersized VPS
Worth planning for specifically: a scenario where many devices reconnect and report simultaneously, after a network outage resolves, for example, creates a genuine traffic spike well above normal steady-state load. An undersized VPS can become temporarily unresponsive during exactly this kind of burst, the worst possible moment for it to struggle, right when you most need visibility into what’s happening across the fleet. Sizing with some headroom above steady-state average load specifically accounts for this pattern, rather than sizing tightly to normal-day usage alone.
What’s the realistic minimum to actually trial ThingsBoard properly, beyond the official 1GB evaluation figure?
2 vCPU and 4GB RAM, the bottom row of the sizing table above, gives a genuinely usable trial with a handful of real devices, enough to judge whether ThingsBoard fits your needs before committing to a larger, production-sized VPS.
Does ThingsBoard support running across multiple VPS instances for high availability, not just for scaling?
Yes, ThingsBoard’s architecture supports clustered deployment across multiple nodes for high availability, a meaningfully more advanced setup than anything covered in this guide’s single-VPS sizing focus, worth investigating specifically if uptime requirements genuinely justify that additional complexity.
How much does telemetry payload size affect sizing, beyond just message frequency?
Meaningfully, a device sending a large JSON payload with many fields per message places more processing and storage load than one sending a single number, worth factoring in if your specific devices report unusually data-rich telemetry rather than simple sensor readings.
Is it worth using a managed PostgreSQL service instead of running it on the same VPS?
For deployments at the upper end of this guide’s sizing table, this is a reasonable middle ground between fully self-hosted and fully managed, letting a specialist database service handle PostgreSQL’s tuning and backups while ThingsBoard itself remains self-hosted, worth weighing against the additional cost and complexity of a third-party database service.
Sizing decisions in practice: a worked progression
A realistic trajectory worth planning for rather than being surprised by: a new ThingsBoard deployment typically starts at the bottom of this guide’s sizing table, comfortable for the first few months while devices are onboarded gradually and the rule chains and dashboards are still being built out. As device count and telemetry frequency grow toward the middle of the table, the first noticeable sign is usually dashboard responsiveness during busy periods, the trigger to check resource usage and consider the next tier up rather than waiting for an outright problem. Each resize, on any of the providers covered in this site’s buying guides, is typically a quick, low-risk operation, meaning there’s little practical cost to starting modestly and growing deliberately as actual usage data, not guesswork, indicates the next step is needed.
This progression, start appropriately small, monitor honestly, resize when the data says to, rather than guessing a large size upfront just in case, is the same sizing philosophy that runs through every VPS-related guide on this site, and ThingsBoard’s resource behaviour, while it has its own specific quirks covered throughout this guide, doesn’t change that underlying principle.
Bringing sizing and setup together
This guide is deliberately the companion piece to ThingsBoard Self-Hosted: Complete VPS Setup Guide, not a replacement for it. A sensible order for anyone new to ThingsBoard: read the setup guide first to understand what’s actually being installed and why, use this guide’s sizing table to choose an appropriately specified VPS before starting, then follow the setup guide’s installation steps on that correctly sized server. Approaching it in this order avoids the common, frustrating experience of installing ThingsBoard on whatever VPS happened to be already provisioned, only to discover partway through onboarding real devices that it was undersized for the job from the start.
A note on the sizing table: it is a confident starting point, not a ceiling, and the monitoring discipline in this site’s uptime guide makes capacity approaching limits visible before they become service-affecting problems.
A practical note on the sizing table’s limits
The sizing table covered earlier in this guide is a genuine starting point, not a precise guarantee. Real-world performance depends heavily on how telemetry is structured (many small messages versus fewer larger ones), how many simultaneous dashboard users are active, and how complex the rule chains running inside ThingsBoard are. The right calibration: treat the table as a confident lower bound for what a given tier handles comfortably, plan for the next tier up when approaching 70-80% of the table’s device count ceiling, and use the monitoring discipline covered in VPS Uptime for 24/7 IoT Operations to catch approaching capacity limits before they become service-affecting problems.
Bringing sizing and setup together
This guide is deliberately the companion piece to ThingsBoard Self-Hosted: Complete VPS Setup Guide, not a replacement for it. A sensible order for anyone new to ThingsBoard: read the setup guide first to understand what’s actually being installed and why, use this guide’s sizing table to choose an appropriately specified VPS before starting, then follow the setup guide’s installation steps on that correctly sized server. Approaching it in this order avoids the common, frustrating experience of installing ThingsBoard on whatever VPS happened to be already provisioned, only to discover partway through onboarding real devices that it was undersized for the job from the start.