Instead of a separate time-series database, start with TimescaleDB

Start Here

Time-series data is just data with a timestamp until scale proves otherwise.

Device readings, product events, billing usage, audit history, and small metrics streams often still need account data, user data, permissions, and normal SQL.

TimescaleDB keeps that work in the Postgres family while adding time-series features.

What To Build First

Start with a hypertable. Keep the schema boring.

create extension if not exists timescaledb;

create table readings (
  ts timestamptz not null,
  device_id text not null,
  value double precision not null
);

select create_hypertable('readings', by_range('ts'));

Now you can query it like a normal table.

select time_bucket('1 hour', ts) as hour, avg(value)
from readings
where ts >= now() - interval '7 days'
group by hour
order by hour;

Good First Uses

Product usage events.
IoT readings.
Billing meters.
Audit timelines.
App metrics that still need joins to product data.

This is a good fit when the time-series data is part of the product, not a separate observability platform.

The Part People Skip

Decide what the timestamp means.

created_at, event time, device time, and ingest time are not the same thing. Pick the one your queries actually mean. If you need more than one, store more than one.

Also decide retention early. Time-series tables grow quietly.

select add_retention_policy('readings', interval '90 days');

If old raw data is not useful, do not keep it forever by accident.

Where Timescale Helps

Hypertables handle time partitioning for you. Continuous aggregates can precompute common rollups. Retention policies can drop old chunks. Compression or columnstore settings can reduce storage for older data.

You do not need all of that on day one. Start with the hypertable, then add features when a real query or storage problem appears.

Move To A Dedicated System When

You are building an observability backend.
Ingestion volume dominates the rest of the product.
The data no longer joins back to product tables.
Storage, retention, and query needs are owned by a separate metrics team.
You need specialized query semantics that SQL is not serving well.

Until then, TimescaleDB is a strong middle ground: more than plain Postgres, less than a new data platform.