Data Storage
Storage Roles, Time-Series Workloads, Lifecycle, and Release Evidence
Data storage turns device messages into durable evidence. A storage design has to answer more than “which database should we use?” It must explain what each record represents, who owns it, how it is queried, how long it stays, how quality problems are handled, and what proof a release must produce before it changes the pipeline.
This book contains fourteen content chapters plus this orientation page. Use the sidebar as the full source of chapter order. Use this page when you need a faster path to the right topic.
Start With the Storage Job
The first decision is the job of the data, not the product name. A device registry, telemetry store, event log, latest-value cache, object store, and archive can all appear in the same IoT platform, but they have different query patterns and failure modes.
What kind of record is this?
Start with Data Storage Overview and Data Storage and Databases when the platform needs a clear separation between registry data, telemetry, events, files, caches, and archives.
Which database behavior matters?
Use Database Selection Framework and CAP Theorem and Database Categories to connect data shape, consistency, partition behavior, and operations.
Will the design survive growth?
Read Sharding Strategies and Data Quality Monitoring when hot partitions, schema drift, duplicate readings, bad timestamps, or quarantine paths matter.
How should measurements age?
Use the time-series chapters when readings arrive continuously and need time-window queries, rollups, retention, downsampling, platform selection, query optimization, or practice labs.
Chapter Chooser
Use the shortest path that matches your current design question. Read in order when you are new to storage; jump directly when you are reviewing an existing platform.
Evidence Loop
Every chapter in this book should lead back to evidence. A storage decision is weak if it cannot show what was accepted, rejected, transformed, stored, summarized, retained, restored, and monitored.
Quality Bar for This Module
One table for every IoT fact
Different data shapes need different constraints, indexes, retention rules, and ownership boundaries.
Database choice before query evidence
Product names are not design evidence. Start with read paths, write paths, consistency needs, failure behavior, and lifecycle.
Retention without restore testing
A retention policy is incomplete until someone can restore or replay the data needed for incident review, audit, or model training.
Untested timestamp assumptions
IoT storage should distinguish device time, gateway receive time, platform ingest time, and processing time when those differences matter.
Suggested Paths
- New to storage: read the overview, storage roles, database selection, CAP theorem, sharding, quality monitoring, and worked examples before moving into the time-series chapters.
- Building a telemetry pipeline: start with time-series databases, fundamentals, database options, platform selection, query optimization, retention, and practice.
- Reviewing an existing platform: scan the chapter chooser, compare the design to the evidence loop, then use the worked examples to test whether each storage decision has measurable proof.
The sidebar remains the complete navigation for this book. Use it to continue with Data Storage Overview or jump to the chapter that matches your current storage question.