Data Storage · Study deck
Time-Series Platform Selection
Picture a cold room that reports one temperature each minute.
Data Dora is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Compare platform patterns by role instead of choosing from generic benchmark claims.
- Explain how InfluxDB-style, TimescaleDB-style, Prometheus-style, and QuestDB-style systems model time-series data.
- Identify platform risks caused by query-language mismatch, unbounded dimensions, retention assumptions, and late data.
- Build a platform decision record that includes evidence, owners, rollback limits, and migration risk.
Major section
Start With the Job, Not the Logo
Those three questions shape the store more than a product name does.
- A time series is a set of values kept with their times.
- A time-series platform stores and searches that kind of record.
- Telemetry means data that a device sends for remote use.
- One platform may suit device readings.
Major section
Start With the Job, Not the Logo (continued)
Another may suit service health or joins with business records.
- Using more than one can be honest when each has a clear job and exit plan.
- Two platforms can both store time-series data and still solve different problems.
- One may fit device telemetry, another may fit SQL joins, another may fit service monitoring, and another may fit high-ingest interval scans.
Major section
In 60 Seconds
InfluxDB-style stores emphasize telemetry ingestion, tag and field modeling, and time-window analytics.
- TimescaleDB-style stores add time partitioning to PostgreSQL so teams can use SQL, joins, governance, and continuous aggregates.
- Prometheus-style stores are built for monitoring, labels, scrape targets, alert rules, and operational evidence.
- QuestDB-style stores focus on ordered timestamp ingestion, partitions, and SQL interval scans.
Major section
Start With the Platform Role
A platform is easier to evaluate when you name the job it is supposed to do.
- The same IoT product may use more than one time-series system: one for device telemetry, one for platform health metrics, one for SQL analytics, and one for archived or replayable history.
Major section
InfluxDB-Style Telemetry Stores
InfluxDB-style systems are often attractive when the core record is a measurement with tags, fields, and a timestamp.
- The review question is not "Is this product fast?" The question is "Does the measurement, tag, field, and timestamp model match the actual query path?".
- That current guidance is different from older InfluxDB advice that treated high tag cardinality as the main failure mode in all versions.
- For a chapter that must age well, keep the learning point stable: put dimensions in the access path only when they support real filters, and test the version you will run.
Major section
Prometheus-Style Monitoring Stores
Prometheus is often the right system for platform health.
- It stores time series identified by a metric name and labels, scrapes configured targets, evaluates rules, and sends alerts.
- That makes it excellent for gateway health, broker queue depth, validation failures, ingest lag, service latency, and infrastructure saturation.
- Prometheus local storage is intentionally a local time-series database with remote storage integration options.
Major section
Evidence Matrix
Candidates are comparable only when they face the same questions.
- Ingest proof tests bursts and rejection, schema proof controls meaning and cardinality, query proof measures the actual access paths, and lifecycle proof covers retention and restore.
- Operations and migration evidence then show whether the team can run, change, and leave the platform safely.
- Missing cells are risks, not neutral scores.
Major section
Common Pitfalls
A product can be excellent for monitoring and weak for regulated raw history.
- Another can be excellent for SQL joins and heavier to operate.
- High-cardinality dimensions can still harm many systems, but the exact behavior depends on the database version, storage engine, query path, and schema.
- SQL, PromQL, Flux, InfluxQL, and platform-specific SQL extensions have different strengths.
Major section
Common Pitfalls (continued)
Prometheus-style monitoring is a good place for gateway health, service latency, queue depth, dropped messages, and validation failures.
- It should not quietly become the only durable store for raw customer telemetry unless the retention, durability, replay, and governance evidence support that role.
- The cheapest time to define export format, dual-write validation, and dashboard migration is before the first production release.
- Without an exit plan, the platform choice becomes a hidden long-term constraint.
Major section
Platform Engine Boundaries
Real time-series platforms cluster into a few shapes rather than one generic "TSDB." A dedicated telemetry store receives pushed measurements and optimizes for tags, fields, retention, and dashboards.
- A SQL hypertable keeps relational SQL while adding time partitioning.
- The first fork that actually matters is push versus pull.
- A concrete IoT fleet makes the boundary visible.
Major section
Platform Engine Boundaries (continued)
A push store must absorb bursts when gateways reconnect and replay buffered readings.
- High-ingest SQL engines and clustered long-retention stores sit beside those roles, but they still need the same workload proof.
- InfluxDB-style and TimescaleDB-style deployments receive writes that clients send them; Prometheus-style monitoring scrapes targets it discovers, pulling metrics over HTTP on an interval.
- A pull monitor must discover 1,200 targets, schedule scrapes, and report when a target disappears.
Major section
Production-Scale Selection Evidence
Work backward from the first three product questions the platform must answer.
- An operations team may ask, "Which gateways have ingest lag above 90 seconds and are dropping validation failures right now?" That points to metrics, recording rules, and alerts.
Major section
Storage Engine Units
Under the product names, mature time-series systems often share one storage idea: buffer recent writes, seal immutable time-partitioned units, compact and compress in the background, and prune by time.
- Newer InfluxDB engines use a different storage stack, so a platform review should always record the exact product version and storage engine being approved.
- TimescaleDB splits a hypertable into chunks partitioned by time and optionally by a space dimension; each chunk is a PostgreSQL child table behind a routing layer.
- A query engine can skip blocks outside the time range and then use the label index to find matching series.
Major section
Storage Engine Units (continued)
Prometheus appends to a write-ahead log and a hot head block, then seals immutable on-disk blocks with chunk files and a label index that compaction can merge into larger ranges.
- In Prometheus, the head block covers recent samples and then turns into block windows, so 15 days of local retention starts as many block ranges before compaction merges them.
- The durable idea is that time-series platforms trade row-by-row mutation for append, partition, compact, and prune.
- Once students can identify the partition unit, index path, and retention drop unit, platform documentation becomes much easier to compare.
Deck summary
Key takeaways
Those three questions shape the store more than a product name does.
- Another may suit service health or joins with business records.
- InfluxDB-style stores emphasize telemetry ingestion, tag and field modeling, and time-window analytics.
- A platform is easier to evaluate when you name the job it is supposed to do.
- InfluxDB-style systems are often attractive when the core record is a measurement with tags, fields, and a timestamp.
Retrieval practice
Recall check 1 of 4
Data Dora says: answer from memory, then check your reasoning.
Q1A maintenance team must join vibration readings with asset ownership, warranty status, site hierarchy, and ticket history using SQL. Which platform pattern should be investigated first?
Show answer
Answer: A The key requirement is time-series storage with relational SQL joins and existing database governance.
Retrieval practice
Recall check 2 of 4
Data Dora says: answer from memory, then check your reasoning.
Q2Place each control where it lives so you can choose a time-series platform from measured workload and operating evidence rather than feature lists.
Show answer
Answer: A These regions connect the decision from evidence to action so you can choose a time-series platform from measured workload and operating evidence rather than feature lists.
Q3Complete the platform decision record with the evidence fields a reviewer should require before release.
Show answer
Answer: A A platform decision record should preserve workload, query, lifecycle, operations, rollback, and ownership evidence.
Retrieval practice
Recall check 3 of 4
Data Dora says: answer from memory, then check your reasoning.
Q4Which statement is the strongest release criterion for a time-series platform selection?
Show answer
Answer: C The decision is defensible when it is backed by evidence across the platform's full role, not only by a product claim.
Retrieval practice
Recall check 4 of 4
Data Dora says: answer from memory, then check your reasoning.
Q5In TimescaleDB, what is a chunk and why does it matter for time-series storage?
Show answer
Answer: A TSM-style files, TimescaleDB chunks, and Prometheus blocks are examples of time-oriented storage units that make pruning, compaction, and retention manageable.
Print reference
Answers 1 of 2
Answer key.
- A · The key requirement is time-series storage with relational SQL joins and existing database governance.
- A · These regions connect the decision from evidence to action so you can choose a time-series platform from measured workload and operating evidence rather than feature lists.
- A · A platform decision record should preserve workload, query, lifecycle, operations, rollback, and ownership evidence.
- C · The decision is defensible when it is backed by evidence across the platform's full role, not only by a product claim.
Print reference
Answers 2 of 2
Answer key.
- A · TSM-style files, TimescaleDB chunks, and Prometheus blocks are examples of time-oriented storage units that make pruning, compaction, and retention manageable.