Characteristics of Time-Series Data
Understand the key traits that define time-series workloads
Tiger Data 101 → TimescaleDB | Section: Working with Time-Series Data | ⏱ Time: ~2 min
Key Characteristics of Time-Series Data
Section titled “Key Characteristics of Time-Series Data”Understanding these traits is essential because they shape every design decision in a time-series database.
1. Append-Only (Rarely Updated or Deleted)
Section titled “1. Append-Only (Rarely Updated or Deleted)”Once a data point is written, it almost never changes. A sensor reading from 2:15 PM doesn't get corrected to a different value; if there's an error, you typically record a new, corrected reading.
Why it matters: Row-based databases optimize for random updates, which wastes space on time-series data. Append-only workloads are a perfect fit for column-based storage and compression.
2. Ordered by Timestamp
Section titled “2. Ordered by Timestamp”Every row has a timestamp, and data naturally arrives in chronological order (or close to it). Old data is almost never inserted out of order.
Why it matters: This ordering enables optimizations like chunk partitioning by time — you can automatically split data into discrete time buckets and manage them independently.
3. High Cardinality
Section titled “3. High Cardinality”You might have thousands or millions of unique series (e.g., device IDs, sensor locations, user IDs, stock symbols).
Why it matters: Indexes on these high-cardinality columns must be efficient, and query plans must avoid expensive full-table scans. TimescaleDB uses adaptive indexing to handle this.
4. High Ingest Rate
Section titled “4. High Ingest Rate”Time-series systems handle thousands to millions of writes per second. A single sensor network alone might produce terabytes of data monthly.
Why it matters: Writes must be fast and cheap. You can't afford the overhead of random-access optimizations (like row-level locking for updates).
5. Time-Range Query Patterns
Section titled “5. Time-Range Query Patterns”Users almost always query by time ranges:
- "Show me CPU usage for all servers in the last hour"
- "Get me daily revenue totals for the past month"
- "What's the average temperature across sensors between 3 PM and 5 PM?"
Why it matters: Queries filter by timestamp ranges, not individual row lookups. This is the opposite of a relational database's typical access pattern.
6. Lifecycle Management
Section titled “6. Lifecycle Management”Old data often needs to be:
- Compressed (save storage)
- Downsampled (aggregate 1-minute readings into 1-hour readings)
- Archived (moved to cold storage)
- Expired (automatically deleted)
Why it matters: Time-series systems need automatic, policy-based lifecycle management to avoid manual intervention.
Real-World Example
Section titled “Real-World Example”Imagine a stock price monitoring system:
- High ingest rate: Prices tick thousands of times per second across all symbols
- Append-only: A price at 10:30:45 AM is final; it's never updated
- High cardinality: Thousands of stock symbols (AAPL, MSFT, TSLA, etc.)
- Time-range queries: "Show me AAPL's price movements in the last hour"
- Lifecycle: Keep 1-second granularity for the last day, compress to 1-minute for the last month, delete after 2 years
A standard relational database would struggle with the write volume and query efficiency. A time-series database is purpose-built for this.