SQL time-series database for telemetry

If you want a SQL time-series database for telemetry, the best fit depends on whether you want:

1. Strict SQL + time-series features
2. Postgres compatibility
3. High ingest / compression
4. Easy self-hosting or managed service

Good options

1. TimescaleDB

• Built on PostgreSQL
• Full SQL support
• Excellent for telemetry, metrics, IoT, events
• Features like hypertables, compression, retention policies, continuous aggregates
• Great if you want a relational database that also handles time-series well

Best for: most telemetry systems that need SQL and strong ecosystem support

2. QuestDB

• SQL query language
• Very fast ingest for time-series
• Good for telemetry / observability / metrics
• More specialized than Postgres-based solutions

Best for: high-write telemetry workloads where speed matters more than full relational features

3. InfluxDB with SQL-like querying

• Primarily time-series focused
• Recent versions support SQL via InfluxQL / Flux / SQL features depending on edition/version
• Popular for metrics and monitoring, but not traditional SQL-first

Best for: telemetry/metrics, if you’re okay with a time-series-native system rather than pure SQL

4. PostgreSQL alone

• If your telemetry volume is modest, plain Postgres with partitioning can work
• Add indexes on time/device_id, use partitioning by time
• Simpler ops, but less specialized than TimescaleDB

Best for: smaller or medium workloads, or when you want to keep architecture simple

My recommendation

• TimescaleDB if you want the most practical SQL time-series database for telemetry.
• QuestDB if ingest/query speed is the top priority.
• Plain PostgreSQL if you want simplicity and your scale is moderate.

Typical telemetry schema

CREATE TABLE telemetry (
  time        TIMESTAMPTZ NOT NULL,
  device_id   TEXT NOT NULL,
  metric_name TEXT NOT NULL,
  value       DOUBLE PRECISION NOT NULL,
  tags        JSONB
);

For TimescaleDB, you’d turn this into a hypertable.

If you want, I can also give you:

• a comparison table
• a schema design for telemetry
• or a recommendation based on your ingest rate / retention / query patterns