Modeling IoT data with tags and fields

WHY IT EXISTS Time-series databases like InfluxDB are built for high-volume, timestamped measurements where you almost always filter and group by metadata and aggregate over time windows. Their tag-and-field model exists to make those filter-and-aggregate queries fast while keeping write throughput high.

THE MENTAL MODEL Think of a measurement (for example, temperature) as a table. Tags are indexed string columns that identify and categorize a point: device_id, location, sensor_type, firmware. Fields are the actual measured values: temperature value, battery level, signal strength. Tags answer where and which; fields answer how much. The crucial concept is series cardinality, the number of unique tag-value combinations, because the index grows with it.

HOW IT WORKS The database indexes tags so queries that filter or group by them, such as all sensors in building A of type humidity, are fast. Fields are not indexed, so filtering directly on a field value scans data and is slow. Each unique combination of measurement plus tag set forms a series, and high cardinality bloats memory and degrades both writes and queries.

WHEN IT MATTERS The right split matters most at scale. Put low, bounded-cardinality, queried-on dimensions in tags. Keep high-cardinality or purely numeric data in fields. Never put unbounded identifiers like a unique event UUID or the raw timestamp into a tag, or cardinality explodes.

ONE CONCRETE EXAMPLE For a fleet of ten thousand sensors, model device_id, location, and sensor_type as tags and store value and battery as fields. Querying average humidity per location over the last hour uses the tag index and runs fast. If instead you stored a per-reading request_id as a tag, every point would create a new series, the cardinality would explode into the millions, and the database would exhaust memory.