Why Is a Relational Database Not the Right Choice for a Time-Series System?

A relational database can store time-series data. The more useful question is whether it is the right database for the scale and access patterns of the system.

To understand the difference, let us begin with a familiar example: managing books in a library.

Key Terms to Talk About

Access patterns · Time-range queries · Aggregations · Write amplification · Write-ahead log (WAL) · Index entries · Composite index · Batching · Series-oriented storage · Time-based blocks

Finding a book in a library

Imagine that a new book is added to a library. We may want to store:

the book’s title;
its author;
its ISBN;
its publisher;
its location in the library; and
whether it is currently available.

Later, someone may ask:

“Do you have this ISBN?”
“Which books were written by this author?”
“Is this book currently available?”
“Which member has borrowed it?”

This is a natural relational database use case. A books table can be related to authors, publishers, members, and loans. Constraints can ensure that an ISBN is unique and that every loan references a valid book and member.

An index acts like the catalogue in a library. Instead of examining every book on every shelf, we look up a title or ISBN in the catalogue and discover where the book is stored.

After locating the book, we use its own table of contents or index to find the page we want to read.

In this use case, the questions are primarily about entities and their relationships:

Find this book.
Find its author.
Find its current borrower.
Update its availability.

The relational model is an excellent fit.

Now consider a gas turbine

Suppose a gas turbine has sensors continuously recording:

temperature;
voltage;
pressure;
vibration; and
rotational speed.

Each sensor sends one reading every second. The questions we ask are very different from the library questions:

“What were the temperature readings between 12 hours 10 minutes and 20 hours 30 minutes?”
“What was the average temperature during that period?”
“What were the minimum, maximum, and 95th-percentile values?”
“How did voltage and temperature change together?”
“Was there an unusual increase in vibration before the turbine stopped?”

We are no longer trying to locate one entity and follow its relationships. We are selecting a continuous time range containing many samples and then aggregating those samples.

The contrast is important:

Book system:
Find a small number of records using an identity or relationship.

Gas turbine system:
Scan a time interval containing many records and calculate aggregates.

The database should be chosen based on the questions the system needs to answer.

What happens in a relational database?

Let us reuse the scale from our earlier example. If a system receives 100,000 samples every second, it receives:

100,000 × 60 × 60 × 24
= 8.64 billion samples per day

A relational database could store each sample as a row:

sensor_id | timestamp | temperature | voltage

Without an appropriate index, finding readings for a time range could require examining an enormous number of rows. A full scan through billions of records would be far too expensive for a frequently executed dashboard query.

We can add an index on timestamp, but that index must contain an entry for every indexed row. At 8.64 billion samples per day, that means up to 8.64 billion new timestamp index entries every day.

If queries also need to locate data efficiently by sensor and timestamp, we might create a composite index:

(sensor_id, timestamp)

If another access pattern requires an index involving temperature, voltage, or a different tag, each additional index also needs entries for the corresponding rows.

This does not mean that the database creates 8.64 billion separate indexes. It means that one index may grow by 8.64 billion entries per day. Two indexes may each receive up to 8.64 billion new entries—roughly 17.28 billion index-entry insertions across both indexes.

The cost is paid on every write

When a new sample arrives, the relational database may need to:

insert the table row;
update every relevant index;
record the changes in its write-ahead log;
maintain transaction guarantees; and
eventually flush the changed pages to durable storage.

A write-ahead log, commonly called a WAL, protects durability and enables recovery. It is extremely valuable for transactional systems. However, recording billions of incoming measurements—and the associated index changes—creates substantial write amplification.

The database can batch transactions and group WAL flushes, so it does not necessarily perform one physical disk flush for every sample. The changes still need to be logged and applied.

Now consider the frequency: this work is not performed once when a book enters a library. It happens 100,000 times every second, continuously.

Additional indexes may speed up reads, but they make every write more expensive:

More indexes → faster access for more query patterns
More indexes → more index entries to maintain on every insert

This trade-off exists in all databases, but it becomes especially visible at time-series scale.

Why a time-series database fits better

A time-series database is designed around the gas-turbine access pattern.

Instead of treating each sample as an unrelated transactional row, it groups samples into series. A series might be identified by:

measurement: temperature
turbine_id:  turbine-17
location:    plant-a

Samples in that series are stored in timestamp order and divided into time-based blocks. This design offers several advantages:

incoming samples can be buffered and written in batches;
nearby timestamps and values can be compressed efficiently;
a range query can skip blocks outside the requested interval;
old partitions can be downsampled or removed as a unit;
common aggregates can be precomputed; and
indexes can focus on stable series tags rather than every measured value.

For the query covering 12 hours 10 minutes to 20 hours 30 minutes, the database can identify the turbine’s temperature series, locate the relevant time blocks, and calculate the requested aggregates.

It does not need an independent general-purpose index for every measurement. The combination of the series identity and timestamp provides the primary access path.

Relational databases are not always wrong

“Not the right choice” does not mean “incapable.”

A relational database is a natural choice when data grows relatively slowly. A library will not magically receive a billion new books every day. It may need a report showing how many books arrived during the last two hours, but that is unlikely to be its most frequent or important query.

The details of the same book are also not updated every second. Its title, author, and ISBN are relatively stable. Availability and loan status may change, but those are occasional transactional updates rather than a continuous stream of measurements.

The exact order in which books arrived is usually not central to the system either. A librarian generally does not need to know which book arrived in the morning, which arrived in the evening, and how their arrival rate changed minute by minute. The library is primarily concerned with the current state of each book and its relationships to authors, members, and loans.

A relational database may be completely reasonable when:

data grows at a predictable and comparatively slow rate;
records represent entities whose details are relatively stable;
the data volume is modest;
transactions and joins are important; or
the team wants to avoid operating another database.

Time-based table partitioning, bulk inserts, careful indexing, and relational extensions can support substantial time-series workloads.

The design begins to strain when ingestion is continuous, retention is long, several indexes must be maintained, and users repeatedly query and aggregate large time ranges. At that point, a specialized time-series database can offer a more efficient storage and query model.

Ask what kind of questions the system answers

For book management, we ask:

Which book is this?
Who wrote it?
Where is it?
Who borrowed it?

For turbine monitoring, we ask:

What happened during this time interval?
How did the measurements change?
What were their aggregates?
Was there an anomaly?

The first workload is centered on entities, relationships, and transactional updates. The second is centered on continuous ingestion, time ranges, and aggregation.

The bottom line is that databases should be chosen according to the output a system needs to produce. Start with the questions users will ask, then work backward to the storage model.

If the system manages relatively stable entities and their relationships, a relational database is often the right fit. If the data changes continuously and the most important questions depend on time, order, ranges, and aggregates, a time-series database is usually the better choice.

That difference—not simply the existence of a timestamp—is why a relational database is natural for a library system, while a time-series database is better suited to large-scale turbine telemetry.