When an IoT payload lands in a database, it is tempting to focus on the value first. 72.4 But a value alone is not yet useful time-series data. Before you choose a schema, connector, or query pattern, you need to know: what produced the value; what the value measures; and when that observation happened. This article uses Apache IoTDB terminology to make that model concrete. It is intentionally a modeling guide, not a syntax tutorial: check the current release documentation before writing DDL or queries. The three fields of context 1. Device: the real-world collection object In Apache IoTDB, a device can be a physical device, a measurement apparatus, or a collection of sensors. In a connected system, that might be a robotic arm, wind turbine, vehicle, meter, or monitoring host. The device answers: Where did this reading come from? That answer should be stable enough to support investigation. If an engineer sees a signal change, they should be able to connect it to a recognizable asset—not just a generic message source. 2. Timeseries: the quantity being observed A timeseries is a measured physical quantity that generates data points over time. Temperature, voltage, current, speed, vibration, humidity, and fuel level are all examples. The timeseries answers: What does this value mean? One device can produce many timeseries. That is why device and measurement should not be collapsed into the same concept. A motor’s temperature and vibration signals may share an asset identity while differing in unit, frequency, data type, and the questions they can answer. 3. Data point: the value at a specific time A data point consists of a timestamp and a value. The timestamp indicates when the data was generated; the value is the result recorded for that timeseries at that time. The data point answers: What was observed, and when? Here is a conceptual record: device: pump-42 measurement: outlet_pressure timestamp: 2026-09-10T09:15:00Z value: 72.4 This is a modeling sketch, not an Apache IoTDB insert statement. The purpose is to show the context you want to preserve. Use a modeling worksheet before defining a schema For each representative signal, complete this small worksheet: Question Example answer What is the device? pump-42 What is the measurement? outlet_pressure What does the value represent? A pressure reading in the approved unit Which timestamp matters? How often is it collected? What will someone ask about it? This worksheet exposes gaps early. If the team cannot state the unit, source, or time meaning of a signal, it will be difficult to make reliable comparisons later. Do not ignore collection frequency Apache IoTDB defines collection frequency as the number of times a physical quantity generates data within a period. It matters because different signals produce different amounts of temporal detail. A vibration signal collected frequently and a temperature signal collected once each minute are both time series, but they should not be interpreted in the same way. Frequency affects the density of observations, the questions a signal can support, and the engineering requirements that follow. Record the expected frequency as part of the signal’s context rather than treating it as an afterthought. Separate observation time from arrival time One implementation detail deserves an explicit question: does the timestamp represent when the source observed the condition, or when another component received the message? Those moments can differ when devices buffer data, gateways reconnect, or networks delay delivery. The appropriate handling depends on the source system and the workload. The practical rule is to name the time semantics before writing the schema. If the source cannot provide a trustworthy observation time, record that limitation instead of silently treating arrival time as the same thing. This makes later investigations more honest and helps prevent misleading comparisons across signals. Device and timeseries stay central in both IoTDB models Apache IoTDB supports a tree model and a table model. Their organization and syntax differ, but both manage devices and timeseries. That means the vocabulary in this article remains useful before you make a model-specific decision. Start with the data and the questions you need to answer. Then use the current Apache IoTDB documentation to choose the appropriate model, define the schema, and validate the implementation with representative data. A pre-ingestion checklist Before wiring a producer to a storage target, check that every reading can answer all of these: □ Which device or sensor group produced it? □ Which physical quantity does it represent? □ What timestamp represents the observation time? □ What are the expected unit, type, and collection frequency? □ Which query, dashboard, or investigation will use it? This is not busywork. It is what makes a future time-range query, trend comparison, or troubleshooting session interpretable. Apache IoTDB is an Apache open-source project for time-series and IoT workloads. For terminology and current data-model concepts, start with the Basic Concepts guide: Basic Concepts | IoTDB Website Basic Concepts 1. General Time Series Database Concepts This section introduces basic concepts commonly used in time series databases, including time series data, time series, d... iotdb.apache.org