IoT telemetry, built on every verified stack.
IoT telemetry: user-owned devices, append-only sensor readings, threshold alert rules, and fired alert instances.
40 verified stacks
Showing 12 across 1 app types. Every stack page links its neighbours along each axis, so any combination is a click or two from here.
What IoT telemetry gives you
The device stamps the time, not the server: sensor_readings.recorded_at is notNull with no default, so whatever the firmware puts on the wire is what lands. A gateway buffering through an outage therefore replays honestly, its backlog keeping true instants instead of collapsing onto the moment it reconnected — and readings arrive out of order as a matter of course, so the latest reading for a device means ordering by recorded_at, never taking a max of anything else. Readings are a narrow long table: device_id, a free-text metric, a value, and that timestamp. On Postgres value is numeric, which is arbitrary precision; on MySQL it is decimal(20,6), because a bare mysql decimal is (10,0) and would silently round every temperature to a whole degree.
Six fractional digits is the ceiling on that side. Devices are the scoping root. device_key is UNIQUE and serves as the hardware's identity at ingest — issued once at provisioning, and the only credential this schema knows about. owner_id foreign-keys Better Auth's user, with idx_device_owner behind the fleet list. status is a stored flag held to 'online' or 'offline' by devices_status_check; it is not derived from readings, so a heartbeat job or the ingest handler has to write it, and it stays wrong until something does. The alerting half is two tables rather than one because a declaration and a firing have different lifetimes.
alert_rules is a per-device threshold — a metric, a comparator held by alert_rules_comparator_check to gt, lt, gte or lte, and a threshold in the same numeric type as value — and nothing stops several rules covering one metric. alerts is the instance: status guarded to 'firing' or 'resolved', triggered_at defaulted, resolved_at nullable until something closes it. It stores both rule_id and device_id even though the device is reachable through the rule, and that redundancy is the point — idx_alert_device answers what is firing on this device with no join. Cascades run the whole way down from devices, so decommissioning one deletes its readings, its rules and its alert history in a single statement. If the telemetry has to outlive the hardware, keep the device row and stop writing to it.
Built for
idx_reading_device_time on (device_id, recorded_at) bounds the scan, and the metric filter is applied inside it — metric is free text with no index, so a second metric on the same chart costs a second pass, not a second index.
devices.device_key is UNIQUE, so one probe turns the key on the wire into the device_id every sensor_readings row is written against. Accepting a reading never touches the user table.
alert_rules is fetched by its device_id foreign key — a handful of rows per device — and comparator, held to gt/lt/gte/lte by alert_rules_comparator_check, picks the comparison against threshold. threshold and value share a type, so no cast enters the compare.
idx_alert_device on alerts.device_id, then status = 'firing' inside that range; resolved_at stays null until something closes the alert, so the two columns have to be written together. alerts carries device_id alongside rule_id precisely so this read never joins through alert_rules.
idx_device_owner on devices.owner_id gathers the fleet, and status is a stored column guarded by devices_status_check, so the split is a group-by over those same rows rather than a rollup across sensor_readings.
Why IoT telemetry, specifically
devices.device_key carries a unique constraint — it is the physical device's identity token and must be generated once at provisioning time, never regenerated.
sensor_readings is append-only (no update path, composite index on device_id + recorded_at) — roll up by device + time window for dashboards rather than mutating any running aggregate.