Guides

How to choose a time-series database

Pick a time-series database by whether you need relational joins, what protocol your data already speaks, and how much cardinality you actually have.

4Analytics · Published September 22, 2026

A time-series database stores time-stamped, usually append-only data — infrastructure metrics, IoT sensor readings, financial ticks — and is optimized for high-volume writes and time-range queries rather than general relational lookups. Teams that need one: infrastructure and platform teams monitoring systems, IoT and sensor platforms, financial and market-data pipelines. Teams that don't: if the data genuinely needs heavy joins against other business entities — customers, orders, products — a general-purpose warehouse, or a relational database with time-series features layered on, may serve better than a purpose-built engine.

Purpose-built versus "Postgres plus"

TimescaleDB is not a separate database — it is an extension that adds automatic time-based partitioning (hypertables), compression and continuous aggregates to PostgreSQL itself, so you keep full relational SQL, joins, and the existing Postgres driver and ORM ecosystem. InfluxDB, QuestDB and VictoriaMetrics are purpose-built from the ground up around time-series access patterns, without general relational overhead. Neither approach is strictly faster; the decision is whether your queries need joins against non-time-series tables in the same statement, in which case TimescaleDB's Postgres foundation is the more direct path.

Monitoring system versus general-purpose store

Prometheus is not a general-purpose time-series database — it is a monitoring and alerting system with one built into it, built around pull-based scraping and its own query language, PromQL, and it has become the default metrics standard for Kubernetes and cloud-native infrastructure. It is deliberately not designed for long-term retention or very high cardinality, which is why teams that outgrow it typically add a remote-write-compatible backend such as VictoriaMetrics rather than replacing Prometheus outright — VictoriaMetrics exists largely as the answer to "Prometheus is running out of room." InfluxDB, QuestDB and TimescaleDB are general-purpose time-series stores usable well beyond infrastructure monitoring — IoT telemetry, application metrics, financial data — and none of them assume a Prometheus-shaped scraping model.

Ingestion protocol compatibility eases migration

Several of these engines deliberately speak each other's ingestion protocols to lower the switching cost. QuestDB accepts the InfluxDB line protocol as well as the Postgres wire protocol, so an existing InfluxDB or Postgres-speaking pipeline can often point at it with minimal change. VictoriaMetrics ingests Prometheus remote-write, Graphite, InfluxDB line protocol and OpenTelemetry directly. Check this before assuming a database switch means rewriting every collection agent — it frequently doesn't.

Cardinality and throughput are the two axes that actually differ

High cardinality — many unique combinations of metric name and labels — is specifically where a single-node Prometheus struggles, and it's the problem VictoriaMetrics and InfluxDB are both explicitly positioned to solve at scale. QuestDB optimizes primarily for raw ingestion throughput with a SIMD-optimized columnar engine, which is why it shows up most often in financial market-data and high-frequency IoT contexts rather than general infrastructure monitoring.

Deployment and managed options

Prometheus has no official managed cloud offering — it is self-hosted by design, with no first-party vendor to buy it from. InfluxDB, QuestDB and TimescaleDB all offer a genuinely free, self-hosted open-source core alongside a separately sold managed cloud service (InfluxDB Cloud, QuestDB Cloud, TimescaleDB's Tiger Cloud). Amazon Timestream is cloud-only, offered either as a native serverless AWS service or as managed InfluxDB running on AWS infrastructure, and makes sense specifically for teams already standardized on AWS who want to avoid operating a cluster themselves.

How pricing scales

Self-hosted open-source cores across this category carry no license fee — the cost is your own infrastructure and operations time. Managed tiers are usage-based but metered differently: InfluxDB Cloud Serverless bills per MB written, per query execution, and per GB-hour stored; Amazon Timestream bills separately for writes, query compute and storage tiering (or by instance-hour for managed InfluxDB); TimescaleDB's Tiger Cloud starts at a flat monthly rate that scales with compute and memory. QuestDB and VictoriaMetrics keep Enterprise pricing custom-quoted with no published rate card.

A shortlist by situation

  • Already on Kubernetes or standardizing infrastructure monitoring for the first time: Prometheus.
  • Outgrowing Prometheus's cardinality or retention limits but want to keep PromQL and existing dashboards: VictoriaMetrics.
  • Purpose-built time series for IoT, sensor or application metrics, with SQL access and a managed cloud option: InfluxDB.
  • Very high write-throughput ingestion — financial market data or dense IoT — with SQL and Postgres wire-protocol compatibility: QuestDB.
  • Already running PostgreSQL and want time-series performance without giving up relational joins and existing tooling: TimescaleDB.
  • Fully AWS-centric and want a managed store with no cluster to run: Amazon Timestream.

Questions to ask vendors or in a trial

  1. What ingestion protocol do our existing agents, exporters or applications already speak, and does the database accept it natively?
  2. What cardinality do we actually expect, in unique series, and does the vendor publish real guidance on limits at that scale?
  3. Do any of our queries need joins against non-time-series, relational data in the same statement?
  4. What does retention and downsampling actually cost once the dataset is large, not just at trial scale?

Common mistakes

Running Prometheus for long-term, high-cardinality storage it was never designed for — without pairing it with a remote-write backend — is the most common one, and it's usually discovered only once storage or query performance degrades. Choosing a purpose-built time-series database when the real requirement is joins against relational business data is a close second; TimescaleDB's Postgres foundation exists precisely for that case. The third is ignoring protocol compatibility and rewriting every ingestion agent from scratch instead of picking a database that already speaks the protocol you have.

Where to go next

InfluxDB vs TimescaleDB and Prometheus vs VictoriaMetrics cover the two most-asked comparisons in this category. See every tool in this category for the full list.

Related tools

Amazon Timestream AWS's managed time-series database, offered as a native serverless service or as managed InfluxDB. InfluxDB Purpose-built time-series database for metrics, sensor and IoT data, available self-hosted or as a managed cloud service. Prometheus Open-source monitoring system with a built-in time-series database, the de facto standard for Kubernetes and infrastructure metrics. QuestDB High-throughput open-source time-series database with SQL, built for fast ingestion of market, IoT and metrics data. TimescaleDB Open-source time-series extension for PostgreSQL, giving full SQL and joins alongside time-series performance. VictoriaMetrics Open-source, Prometheus-compatible time-series database and monitoring backend built for high cardinality at low cost.

Terms used in this guide

Time-series database A database purpose-built for data points indexed by time, optimized for fast writes and time-range queries. Data ingestion Moving data from its source systems into a storage or processing system where it can be transformed and analyzed. Dashboard A visual display of the metrics a team needs to monitor, usually updated on a schedule or in real time. Health Insurance Portability and Accountability Act (HIPAA) The U.S. law that sets privacy and security rules for protected health information handled by healthcare providers and insurers.

Latest on this topic