An IoT platform ingests a temperature reading from 50,000 sensors every second. Queries ask for averages per five-minute window over the last day, and readings older than 90 days are downsampled to hourly values. Which database type best fits this workload?
Select an answer to reveal the explanation.
Short Explanation
When every record is "this value at this moment" and almost every query starts with "between these times," you're in time-series country. These engines are built for nonstop appends, time-window rollups and downsampling old data. Don't let the word "sensor" tempt you toward a flexible document store.
Full Explanation
Time-series databases are designed for data points that each carry a timestamp and arrive in roughly chronological order at high volume. They optimize for append-heavy ingestion, store and compress data in time-ordered chunks, and provide native operations for window aggregation, such as averaging readings into five-minute buckets. Many also support retention and downsampling policies that roll older raw data into coarser summaries, which matches the 90-day requirement directly. A graph database models entities and relationships for traversal; storing each reading as a node would add edge overhead with no benefit for time-range aggregation. An object-oriented database persists application objects with their class structure and references, which suits complex engineering models rather than streams of simple timestamped measurements. A document database can store readings as JSON, but it lacks the time-partitioned storage, compression and built-in windowing that make a purpose-built time-series engine efficient at this volume. Exam caveat: relational engines with time partitioning can handle moderate time-series loads, but the question asks which type is built for this shape of data. Operational check: load a day of sample readings, run the five-minute window average for one sensor, and verify both ingest rate and query latency against the platform's requirements.