Time-Series Databases: Optimized for Data Over Time

WHY IT EXISTS General-purpose databases are not built for the unique workload of time-series data: constant, high-volume writes of timestamped records, and queries that aggregate data over time ranges. A relational database would struggle with indexing performance and storage bloat under this load. TSDBs were created to solve this specific problem efficiently.

THE MENTAL MODEL Think of a TSDB not as a set of complex, related tables, but as a hyper-efficient logbook. For every metric you're measuring (a server's CPU, a stock's price), it keeps a long, ordered list of timestamp-value pairs. Its main job is to write new entries to this list very fast and read back ranges or aggregates (like averages) just as quickly.

HOW IT WORKS A TSDB's design makes time a first-class citizen. Time is always a key part of the index, making queries like "find all data points between last Tuesday and yesterday" extremely fast. They ingest high-volume writes by appending data, rather than performing complex updates. To manage storage, they use specialized compression algorithms that are effective on sequential data, like storing only the difference from the previous value instead of the full value each time.

WHEN TO USE IT Use a TSDB for any application collecting measurements over time where your primary queries are time-based. This includes monitoring and observability (system metrics, application performance), IoT applications (sensor data from industrial equipment), and financial data (stock prices, trading volumes). If your question is "how did this metric change over the last N hours?", a TSDB is the right tool.

WHEN NOT TO USE IT A TSDB is the wrong choice for data with complex relationships, which is the strength of a relational database. If you need to model customers, orders, and products with joins and foreign keys, a TSDB is not suitable. They are also not ideal for data that is frequently updated in place, as TSDBs are optimized for append-only writes.

ONE CANONICAL EXAMPLE A classic use case is monitoring server CPU utilization. An agent sends a data point every 10 seconds: {timestamp: 1677657600, metric: 'cpu.usage', host: 'web-01', value: 15.5}. A TSDB ingests millions of these from thousands of servers. An engineer can then instantly query it to graph the average CPU usage for all web servers over the past 24 hours, a task that would be slow and inefficient in a standard database.