Time Series Database: A Logbook, Not a Filing Cabinet
A Time Series Database (TSDB) is a specialized logbook for data that happens over time, like server metrics or sensor readings. It's built for high-speed writes and fast range queries. The footgun: don't use it for relational data like user profiles.
WHY IT EXISTS Standard relational databases struggle with the sheer volume and velocity of data from monitoring and IoT systems. Their structure, optimized for complex relationships, becomes slow and inefficient when constantly appending new time-stamped values and querying for time ranges.
THE MENTAL MODEL A Time Series Database (TSDB) is like a hyper-specialized logbook. Its one job is to record a value at a specific time, do it extremely fast, and make it easy to look up everything that happened within a specific time window. It trades the flexibility of a general-purpose database for extreme efficiency at this one task.
HOW IT WORKS A TSDB's primary index is always time. This makes queries like "give me all CPU measurements from last Tuesday" incredibly fast because the data is already organized chronologically. It also heavily uses compression, as consecutive measurements (like temperature readings one second apart) are often very similar and can be stored efficiently.
WHEN TO USE IT Use a TSDB for any high-volume, time-ordered data. This includes application performance monitoring (server CPU, memory, latency), IoT sensor data (temperature, pressure from factory equipment), and financial data (stock prices over time). If your main question is "what was the value of X over Y time?", a TSDB is a good fit.
WHEN NOT TO USE IT Avoid TSDBs for data that isn't primarily defined by time. User profiles, product catalogs, or transactional order data are poor fits. These require complex relationships and non-time-based lookups, which are the strengths of relational or document databases.
ONE CANONICAL EXAMPLE A DevOps team monitors thousands of servers, each reporting CPU usage every 10 seconds. A TSDB ingests this firehose of data. An engineer can then instantly query for the average CPU usage across all web servers during a specific deployment window to see if the new code caused a spike in resource consumption.
Read the original → en.wikipedia.org
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.