# Time-series databases > A time-series database stores timestamped measurements and makes time-range queries and aggregations efficient. In system design interviews, it fits workloads such as monitoring metrics and historical event counts, where write volume, retention, and query cost matter more than arbitrary record updates. Source: https://sysround.com/concepts/time-series-databases Updated: 2026-11-05 ## How time-series databases works Start with the data model: a measurement name, timestamp, dimensions or tags, and numeric values. For example, cpu_usage{host="h17", region="us-east"} at 12:00:00 has value 0.72. In a common metrics model, the measurement name plus its complete tag set identifies a series; each timestamped value is a sample in that series. Design around actual queries, such as “average CPU by region over the last hour.” Indexes locate matching series, and time bounds restrict which samples are scanned. A relational database with suitable indexes and time partitioning can also support this model; a specialized database becomes useful when ingestion, compression, or time-range aggregation requirements justify it. Partition data into time intervals and, at larger scale, distribute each interval by a hash of the series identity or another routing key. Time partitioning enables pruning and expiration, while hash partitioning spreads current writes across machines. Partitioning only by time can send all current traffic to one hot partition. Buffer and batch incoming samples, then organize them into storage blocks. Many engines compress timestamps and nearby values effectively because samples within a series are repetitive. Persistence, replication, and acknowledgment policies still need explicit choices; a time-series database does not automatically make ingestion lossless. Keep recent samples at full resolution and create coarser rollups for older data. For example, retain 10-second samples for seven days and five-minute summaries for a year. Store sum and count if later queries need weighted averages; averaging bucket averages gives incorrect results when bucket counts differ. Define how retries, late samples, and expiration interact. A sample identified by series and timestamp might be rejected, replaced, or merged depending on the engine and schema. Choose a late-arrival window, explain how affected rollups are corrected, and expire old time partitions once retention permits. ## Worked example: Sizing a metrics store with bounded retention Suppose 10,000 hosts each emit 20 gauge series every 10 seconds. That produces 200,000 active series, 20,000 samples per second, and 1.728 billion samples per day. Keep raw samples for seven days: 12.096 billion samples before replication and storage overhead. Partition by day and hash series identities across shards so current writes do not hit one machine. Create five-minute rollups with sum, count, minimum, and maximum, retaining them for one year. A one-hour dashboard reads raw data; a six-month trend reads rollups. Reject unbounded labels such as request IDs, define a late-arrival window, and make retried writes safe using the database's documented duplicate semantics. ## Trade-offs - **Fast time-range queries, narrower flexibility.** Time-oriented layouts favor bounded scans and aggregations but may be a poor fit for arbitrary joins, transactional updates, or event-level exploration. - **Rich dimensions versus series cardinality.** Each distinct tag combination can create another series, so unbounded labels such as request IDs can exhaust index memory and increase query fan-out. - **Historical precision versus storage cost.** Rollups reduce storage and scan work but discard detail that cannot be recovered after raw samples expire. - **Write distribution versus read fan-out.** Hashing series across shards spreads ingestion, but queries covering many series must aggregate results across those shards. - **Freshness versus ingestion efficiency.** Larger batches improve write efficiency and compression opportunities but delay visibility and require buffering capacity. - **Late-data correctness versus operational complexity.** Accepting old or corrected samples can require reopening storage blocks and updating aggregates rather than treating historical buckets as final. ## When to use it in a system design interview - The workload continuously records numeric measurements, and most reads filter by dimensions and a bounded time range. - Dashboards or alerts need repeated aggregations such as rates, averages, maxima, or histogram-based percentiles. - Data has an explicit lifecycle: high-resolution recent history, coarser older history, and eventual expiration. - Estimated sample volume or query cost exceeds what a simpler indexed and partitioned relational table can comfortably support. ## How to bring it up in the interview - Start with a sample record and two representative queries, then justify the storage choice from those access patterns rather than saying that all timestamped data needs a time-series database. - Estimate active series, samples per second, and retention volume separately: active series multiplied by sampling frequency determines baseline ingestion, while series churn adds index and metadata costs. - State the partition key and explain both write distribution and query fan-out; expect follow-ups about hot tenants, broad dashboards, and adding shards. - Define metric semantics before aggregation: counters need reset-aware rates, gauges represent observations, and percentiles require mergeable distributions rather than averages of local percentiles. - Explain duplicate handling, accepted lateness, rollup corrections, and missing-data behavior; interviewers often probe whether an empty interval means zero, delayed ingestion, or a failed collector. ## Common mistakes - Adding user IDs, request IDs, or other unbounded dimensions as tags without a cardinality budget. - Partitioning solely by timestamp and assuming that this distributes concurrent writes across machines. - Averaging averages or percentiles across buckets without preserving the information needed for a correct merge. - Assuming timestamps are unique, clocks agree, or retried writes are automatically deduplicated. - Using a time-series database as a substitute for a billing ledger, event archive, or full analytical warehouse when those workloads need different guarantees or query patterns. ## Interview questions where it comes up - [Design a metrics monitoring system like Datadog](https://sysround.com/questions/design-metrics-monitoring-system): The core storage design must handle series cardinality, sample ingestion, retention, rollup accuracy, and alert queries. - [Design an ad click aggregator](https://sysround.com/questions/design-ad-click-aggregator): Time-bucketed count storage and corrected rollups are central to serving fast window totals despite duplicate and late events. - [Design Google Analytics](https://sysround.com/questions/design-google-analytics): The design needs dimensioned time-bucket aggregates and retention policies for dashboards, while distinguishing those summaries from event-level analytical storage. ## FAQ ### What is a time series data model? A common model contains a timestamp, a measurement name, dimensions or tags identifying the series, and one or more measured values. For example, a temperature series might be identified by sensor ID and location, with a new timestamped reading every minute. Exact terminology and uniqueness rules vary by database. ### How is a time-series database different from a relational database? Time-series databases emphasize time-range scans, high-volume sample ingestion, compression, retention, and often built-in time aggregations. Relational databases can store the same logical data and may be sufficient with appropriate indexes and partitioning. Choose based on workload and operational requirements, not simply the presence of a timestamp column. ### What is high cardinality in a time-series database? Cardinality commonly refers to the number of distinct series created by measurement names and tag combinations. Adding a request ID can turn a small set of reusable series into a stream of unique ones, increasing index size and ingestion overhead. Bound dimensions, monitor series churn, and keep event-level identifiers in a more suitable event or log store. ## Related concepts - [Partitioning strategies](https://sysround.com/concepts/data-partitioning) - [Columnar storage](https://sysround.com/concepts/columnar-storage) - [Windowing and watermarks](https://sysround.com/concepts/windowing) - [Observability](https://sysround.com/concepts/observability) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.