ormDB for IoT Data Platforms
ormDB serves IoT data platforms with graph fetches for complex device-fleet-customer hierarchies, R-tree indexed geo search for location-aware device queries, and change streams that push real-time device telemetry without polling.
IoT data is relational and location-aware
IoT platforms manage devices organized into fleets, owned by customers, deployed across geographic regions. Each device has telemetry data, status history, and configuration. Querying this hierarchy with traditional databases means N+1 queries or complex joins.
ormDB for device management
ormDB is a relational database engine with native graph queries and geo search. Load a fleet with all its devices, their current status, and their locations in one graph fetch.
Geo search with R-tree indexes supports radius queries, bounding box, and polygon containment — find all devices within a geographic region without PostGIS.
Change streams push real-time device status updates to monitoring dashboards. Query budgets prevent expensive queries from impacting the platform when querying across large device fleets.
Finding devices in space and in the hierarchy
A location-aware fleet query combines geo search with a native graph traversal in one request:
graph_fetch Device (
location within_radius(lat: 37.77, lng: -122.42, km: 5),
status = "online"
) {
serialNumber, status, lastSeenAt, location,
fleet {
name,
customer { name, region }
}
} [budget: 5000]One fetch returns every online device near a point, already joined up to its fleet and customer, with a budget guarding against runaway traversals.
Where ormDB fits — and where it does not
ormDB is in Alpha (v0.1.0) and is a relational engine, not a specialized time-series or streaming system. For the device/fleet/customer control plane, geospatial queries, and real-time status, it consolidates work that would otherwise span PostgreSQL, PostGIS, and a CDC pipeline. For raw high-frequency telemetry ingestion at massive scale, pair it with a dedicated time-series store rather than treating ormDB as one. If you are evaluating options, the microservices best-database guide covers related architecture tradeoffs.
Frequently Asked Questions
Can ormDB handle IoT device management?
Yes. Device fleets with hierarchical relationships (device → fleet → customer → region) load in single graph fetches. Geo search finds devices by location. Change streams push real-time device status updates.
Is ormDB a time-series database?
No. ormDB is a relational engine, not a purpose-built time-series store. It excels at the device, fleet, and customer relationship graph and at geo and change-stream workloads. For very high-cardinality, high-write telemetry ingestion you may still pair it with a dedicated time-series database or downsample before storing.
How does geo search work for device fleets?
ormDB indexes location fields with an R-tree, so radius, bounding-box, and polygon-containment queries run natively — for example 'all online devices within 5 km of this substation' — without installing PostGIS or a separate geospatial service.
How do change streams drive real-time monitoring?
When a device's status or telemetry entity changes, ormDB emits a structured delta event with a version token. Monitoring dashboards and alerting pipelines subscribe to the streams and react to exactly what changed, instead of repeatedly polling every device row.
How do query budgets protect the platform?
A misconfigured client could ask for an entire fleet with deep nested relations. Query budgets cap max depth, fanout per relation, total rows, and execution time, so one expensive query is rejected rather than degrading the whole platform.