Industrial IoT Pipeline: EMQX MQTT Broker + TimescaleDB Hypertable Sizing
TimescaleOps blueprint for sizing vCPU, DDR5 RAM, Linux socket limits, and batch COPY buffers for 10,000 to 250,000 MQTT sensors writing into TimescaleDB.
Opening individual PostgreSQL connections per MQTT packet from 50,000 factory PLCs or solar inverters exhausts backend process slots immediately. Pairing EMQX sink batching with a medium-wide TimescaleDB hypertable consolidates thousands of sensor frames into sequential WAL writes on a single NVMe VPS.
| Telemetry Scale | Chunk / Partition Interval | Server DDR5 RAM | Retained Disk Footprint | Matched Infrastructure Tier |
|---|---|---|---|---|
| 2,500 Devices • 1K msg/s | 7d |
8 GB DDR5 | 100 GB Gen4 NVMe | Hostinger KVM 2 ($5.99/mo) |
| 25,000 Devices • 10K msg/s | 1d |
16 GB DDR5 | 400 GB Gen4 NVMe | Hostinger KVM 8 / UltaHost VDS |
| 100,000 Devices • 50K msg/s | 6h |
32 GB DDR5 | 2 TB NVMe / ZFS | InterServer Ryzen Storage |
| 250,000+ Fleet • 150K msg/s | 6h / 1h |
64 GB DDR5 | 6 TB ZFS Vault | UltaHost VDS 64GB + InterServer |
# /etc/sysctl.d/99-emqx-timescale.conf
fs.file-max = 2097152
net.core.somaxconn = 65535
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1
-- Medium-wide IoT telemetry hypertable (10 sensor readings per tuple)
CREATE TABLE iot_sensor_telemetry (
ts TIMESTAMPTZ NOT NULL,
site_id SMALLINT NOT NULL,
device_id INTEGER NOT NULL,
temp_c REAL,
vibration_rms REAL,
voltage_v REAL,
current_a REAL,
humidity_pct REAL,
status_code SMALLINT
);
SELECT create_hypertable('iot_sensor_telemetry', by_range('ts', INTERVAL '1 day'));1. Why Medium-Wide TimescaleDB Hypertables Beat Narrow EAV Schemas on Disk
In PostgreSQL 16, every row carries a 23-byte HeapTupleHeaderData prefix plus alignment padding and B-tree index pointers. Storing 10 sensor readings as 10 narrow EAV rows (ts, device_id, metric_name, value) duplicates ~39 bytes of tuple header and key metadata ten times per payload. Grouping those 10 REAL float4 columns into one 80-byte hypertable row cuts raw heap and index RAM overhead by more than 75%.
2. EMQX Sink Batching Into TimescaleDB: Flush Every 5,000 Rows or 500ms
Configure your EMQX bridge, Telegraf output, or Vector sink with batch_size = 5000 and linger_ms = 500. Batching converts 10,000 separate network round-trips per second into two sequential PostgreSQL WAL commits per second.
3. Sizing a 7-Day Uncompressed TimescaleDB Hot Window for Offline Cellular Gateways
Maritime, agricultural, and mining gateways buffer 48 to 96 hours of telemetry on local flash during cellular blackouts. Keeping uncompressed hot chunks open for 7 days lets delayed batches insert directly into standard B-tree pages without triggering compressed-chunk staging merges.
TimescaleOps Engineering Q&A: TS-04 // EMQX-IOT Hypertable Operations
Can EMQX and TimescaleDB share a single 16 GB DDR5 KVM VPS?
Yes, for fleets up to roughly 10,000 to 15,000 messages/sec when properly batched. Pin EMQX Erlang schedulers to 2 vCPUs and reserve the remaining vCPUs plus 4 GB shared_buffers for PostgreSQL.
Should IoT hypertables use REAL (float4) or DOUBLE PRECISION (float8) columns in TimescaleDB?
Use REAL (4 bytes, ~7 decimal digits of precision) for physical telemetry such as temperature, pressure, and voltage; reserve 8-byte DOUBLE PRECISION for cumulative utility billing counters and GPS coordinates.
What happens in TimescaleDB if late IoT sensor batches arrive for a compressed hypertable chunk?
TimescaleDB 2.11+ accepts INSERTs into compressed chunks via a mutable staging table that merges asynchronously, though sizing your hot window to cover typical offline durations minimizes background recompression I/O.