Understanding Time Series Databases: Data Models, Architecture, and How to Choose One

Understanding time series databases means understanding databases optimized for timestamped measurements and events, such as metrics, sensor readings, telemetry, and financial ticks. A TSDB improves time-range ingestion, time-window aggregation, compression, retention, and downsampling, but a timestamp column alone does not make PostgreSQL or another database a TSDB.

The important decision is workload fit, not the label “time-series.” Prometheus, InfluxDB, VictoriaMetrics, TimescaleDB, QuestDB, and ClickHouse solve overlapping but different problems. The best choice depends on ingestion rate, active-series cardinality, query language, joins, late data, retention, correctness requirements, cost, and how much infrastructure your team wants to operate.

Key takeaways

• A time series database is optimized for timestamped observations or events, time-range queries, time-window aggregation, compression, and data lifecycle operations such as retention and downsampling.
• Cardinality means the number of distinct series, not the total number of samples; unbounded labels such as request IDs and full URLs can create expensive series explosions.
• Prometheus is a monitoring-native metrics system, while InfluxDB and other general-purpose TSDBs are better suited to many telemetry and sensor workloads; Prometheus-compatible storage is not automatically a complete Prometheus replacement.
• PostgreSQL may be the right choice when volume is moderate and transactions, joins, and mutable business data matter more than specialized time-series ingestion.
• Retention, downsampling, tiering, duplicate handling, late-arriving data, backups, and deletion requirements should be designed before production ingestion begins.

What is a time series database?

A time series database is a database optimized for data whose most important dimension is time. Each observation normally contains a timestamp, a value or event payload, and an identity made from dimensions such as device, host, customer, region, metric, or asset.

A TSDB is not defined merely by having a timestamp column. PostgreSQL, MySQL, ClickHouse, object stores, and data warehouses can all store timestamped records. A specialized TSDB earns its name through optimizations and operational features for continuous or high-volume ingestion, time-range scans, time-window aggregation, compression, large numbers of series, retention, expiration, tiering, and rollups.

Time-series database is best treated as a workload category rather than one uniform product category. ClickHouse’s overview of time-series databases distinguishes purpose-built systems, relational extensions such as TimescaleDB, and broader analytical platforms such as ClickHouse and Apache Pinot. Those categories overlap, but the differences matter when selecting a system.

What counts as time-series data?

Time-series data is data observed or generated over time. Common examples include CPU utilization collected every 15 seconds, industrial temperature readings, stock trades, API latency, vehicle GPS positions, energy consumption, application counters, and machine-learning model-monitoring values.

Not every timestamped record has the same shape or requirements:

Data type	What it represents	Typical storage question
Measurement	A value observed at a point in time, such as temperature or power draw	What was the value during a time range, and how did the value change?
Metric	An instrumented measurement used for monitoring, dashboards, or alerts	What is the rate, percentile, error ratio, or current state?
Event	Something that happened at a particular time, often with attributes rather than one numeric value	Which events occurred, and how many occurred in each time window?
Log	A discrete occurrence with text or semi-structured payloads	What happened in this interval, and what request or error details were recorded?
Trace	A distributed request journey made from spans	Which services contributed to latency or failure?

A metric is not the same thing as an event log. A metric such as request_count = 1 records an aggregate observation; the metric does not preserve every request ID, payload, stack trace, or audit detail. Systems often store metrics in a TSDB while sending logs and traces to systems designed for text search and distributed tracing.

How does a time series database model data?

A time-series data model usually separates time, series identity, and measured values. Product terminology differs, but the underlying design questions are similar.

Timestamp: when did the observation happen?

The timestamp may represent event time, ingestion time, or processing time. Event time is when the measured event happened; ingestion time is when the database received the record; processing time is when a pipeline handled the record. The three timestamps are not interchangeable, especially when devices disconnect or pipelines process data late.

Timestamp precision and default behavior are product-specific. For example, InfluxDB’s glossary documents Unix timestamps with nanosecond precision and explains how an omitted timestamp can be assigned by the server in UTC. That behavior should not be generalized to every TSDB.

What is a series?

A series is a stream of observations sharing one identity. A conceptual monitoring series might be identified as follows:

metric: cpu_usage
host: web-01
region: us-east
environment: production

In a label-based system, changing any identity dimension creates another series. Prometheus defines a series through a metric name and its complete set of labels. A metric with the same name but a different host or status label is therefore a different series.

What are tags, labels, dimensions, and fields?

Different systems use different names for similar concepts:

• Prometheus: metric names and labels.
• InfluxDB: measurements, tags, fields, and timestamps.
• SQL systems: tables, columns, indexes, partitions, and sort keys.
• Columnar analytical systems: ordinary columns combined with partitioning, ordering, and compression.

Put values used repeatedly for filtering, grouping, or series identification into dimensions only when the resulting cardinality is manageable. Keep large, unique, or rarely filtered values in fields or event columns where the engine supports them. A request ID can be useful in a trace or log, but a request ID is usually a poor metric label.

What is cardinality, and why does cardinality matter?

Cardinality is the number of distinct time series. Cardinality is different from sample count: one series can contain millions of samples, while millions of series can each contain only a few samples. The two workloads stress different parts of a database.

VictoriaMetrics defines cardinality as the number of unique time series and explains that high cardinality increases resource usage. Prometheus’s metric-name-and-label model makes the same practical implication clear: every unique combination of metric name and labels is a separate series.

For example, these dimensions could theoretically create up to 2 million combinations:

host:         10,000 possible values
region:       10 possible values
status_code:  20 possible values
10,000 × 10 × 20 = 2,000,000 possible series

The theoretical maximum is not necessarily the actual count, because not every combination may exist. The example still demonstrates why cardinality must be measured separately from total data volume.

What is a safe label design?

A poor design places an unbounded identifier in the series identity:

http_latency{request_id="8f1..."} 120

A more appropriate metric design uses bounded dimensions:

http_latency{service="api", route="/orders", method="GET", status="2xx"} 120

The unique request ID belongs in a trace or log, where individual request details can be retained without multiplying the number of metric series. Route templates such as /orders/:id are generally safer than raw URLs containing arbitrary IDs, although the correct dimensions depend on the monitoring objective.

Why do specialized time-series databases help?

TSDB storage engines are designed around append-heavy writes and queries that select and aggregate time ranges. Implementations differ, but common techniques include time-based partitioning, write-ahead logs, memory buffers, immutable blocks or files, compaction, timestamp and value compression, dimension indexes, columnar storage, tiered storage, object-storage history, and materialized rollups.

How does time-based partitioning work?

Time-based partitioning divides data into time ranges such as hours, days, or weeks. A query for the last hour can skip partitions outside that interval, and a retention process can often remove an entire old partition instead of deleting individual rows.

Time partitions also let a system keep recent data on fast storage, compact older data independently, and move historical partitions to cheaper storage. Partition size is a trade-off:

Partition choice	Potential benefit	Potential cost
Very small time ranges	Fine-grained expiration and selective reads	More metadata, files, indexes, and management overhead
Very large time ranges	Fewer partitions and less partition metadata	Less selective reads and less convenient compaction or deletion
Workload-sized ranges	Balances ingestion, queries, compaction, and retention	Requires measurement rather than a universal setting

The appropriate partition duration depends on ingest volume, query ranges, storage hardware, compaction behavior, and retention policy. A partitioning recommendation copied from one engine should not be assumed to fit another engine.

How do TSDBs use write-ahead logs, blocks, and compaction?

A write-ahead log, or WAL, records writes durably before data is fully organized for querying. In-memory buffers can accept recent writes quickly, while immutable blocks or files provide an efficient structure for reads. Compaction later merges smaller structures, removes obsolete representations, and improves read efficiency.

Prometheus local storage stores samples in two-hour blocks containing an index, chunks, and metadata, while a WAL protects current in-memory data. Prometheus’s storage design is optimized for its monitoring workload and can integrate with remote storage; the design should not be treated as a universal TSDB blueprint.

Older InfluxDB 1.x and 2.x-era TSM documentation describes a WAL and sorted, compressed TSM files organized into time-based shards. That explanation is useful for understanding the historical TSM engine, but it should not automatically be applied to InfluxDB 3. InfluxDB 3 documentation describes a newer Apache Arrow and object-storage-based architecture, with SQL and InfluxQL support.

Why does compression work well for some time-series data?

Time-series data often contains monotonically increasing timestamps, predictable timestamp deltas, repeated values, slowly changing measurements, and numeric columns with similar distributions. Those patterns can compress effectively.

Compression is workload-specific. Compression results depend on timestamp regularity, value distribution, schema, data types, partitioning, retention, and the storage engine. A benchmark using regular sensor samples should not be used to predict storage for irregular financial ticks or high-cardinality application metrics. VictoriaMetrics documents value compression and related time-series storage capabilities, but a vendor description is not a universal compression guarantee.

How do retention, downsampling, and tiering change the data lifecycle?

Retention automatically deletes data after a configured period. Downsampling replaces high-resolution history with lower-resolution aggregates. Tiering moves older data to slower or cheaper storage. Rollups are precomputed summaries such as minimum, maximum, average, count, sum, percentiles, or histogram data.

A practical lifecycle might look like this:

Age	Stored representation	Purpose
0–7 days	10-second raw data	Detailed troubleshooting and incident investigation
8–90 days	1-minute aggregates	Operational trends and dashboard history
91–730 days	1-hour aggregates	Capacity planning and seasonal comparisons
Older than 730 days	Exported archive or deleted data	Compliance, research, or controlled long-term retention

Downsampling can save storage and query work, but downsampling changes which questions remain answerable. An average alone can hide spikes. Monitoring and capacity planning often need minimum, maximum, average, count, and rates. Latency analysis often needs histograms or quantiles rather than only an average.

InfluxDB documents retention and downsampling concepts, and VictoriaMetrics documents downsampling and retention-related capabilities. Retention is not the same as archival: deletion removes data, while tiering or archiving preserves data in another form.

What queries do time-series databases optimize?

Time-series queries usually select a time range, filter by dimensions, group records into time buckets, calculate aggregates, compare periods, calculate rates or changes, find gaps, detect anomalies, or evaluate alert conditions.

What does a time-window aggregation look like?

The following is a TimescaleDB-style SQL example, not portable SQL. The time_bucket function groups readings into five-minute intervals:

SELECT
  time_bucket('5 minutes', recorded_at) AS bucket,
  device_id,
  avg(temperature) AS mean_temperature,
  min(temperature) AS minimum_temperature,
  max(temperature) AS maximum_temperature
FROM sensor_readings
WHERE recorded_at >= now() - interval '24 hours'
GROUP BY bucket, device_id
ORDER BY bucket, device_id;

The query asks for a time range, a time bucket, a device dimension, and several aggregates. A conventional relational database can execute a query like this, but a time-series extension or specialized engine may provide more convenient partitioning, compression, continuous aggregates, or retention features for a large recurring workload.

What does a PromQL time-series query look like?

PromQL is designed around labeled metric series and time-aware operations. This query calculates a five-minute rate from a counter:

rate(http_requests_total[5m])

The syntax is PromQL-style and should not be assumed to work in a SQL-only TSDB. Prometheus documentation explains the metric and label data model; exact functions, counter behavior, staleness rules, and alert semantics should be checked against the specific Prometheus-compatible engine.

Which time-series query problems need special care?

• Rates and counters: A counter that resets after a process restart needs counter-aware functions rather than a simple difference.
• Moving averages: The window definition must distinguish missing observations from zero values.
• Gaps: A missing sensor report is not automatically a measurement of zero.
• Irregular sampling: Financial trades and change-only sensors may require interpolation, last-known-value logic, or explicit gap handling.
• Historical comparisons: Comparing today with last week requires consistent time zones, aggregation rules, and retention resolution.
• Joins: Joining telemetry to customers, assets, contracts, or geography may favor SQL and a relational or analytical engine.

How do ingestion models differ?

Time-series systems accept data through several ingestion models. Pull or scrape collection is common in Prometheus, while application and IoT systems often push measurements. Batch ingestion, streaming ingestion, remote write, and bulk historical import are also common.

Ingestion model	Typical use	Design questions
Pull or scrape	Infrastructure and application metrics	Who discovers targets, controls sampling, handles scrape failures, and authenticates?
Push	Applications, sensors, and devices	How are retries, backpressure, duplicates, and device outages handled?
Streaming	Continuous event or telemetry pipelines	What is the event-time policy, ordering guarantee, and replay behavior?
Batch or bulk import	Historical migration and periodic exports	Can the system accept backfills without disrupting recent ingestion?
Remote write	Long-term storage for monitoring metrics	Does protocol compatibility preserve the required query, alerting, and rule semantics?

Ingestion architecture affects failure recovery, backpressure, timestamp authority, network topology, security, duplicate handling, and whether the collector or database controls sampling. Accepting Prometheus remote write does not automatically make a database a drop-in replacement for Prometheus’s service discovery, alerting, recording rules, or ecosystem.

How should a system handle late and out-of-order data?

Late-arriving data should be treated as a first-class design requirement. Before choosing a TSDB, determine whether the engine accepts samples older than the newest point, how far back late data can arrive, whether out-of-order writes trigger expensive rewrites or compaction, and how duplicate timestamps are handled.

Ask these questions explicitly:

• Does the system accept event timestamps older than the latest ingested timestamp?
• How far back can a device or pipeline backfill data?
• Are duplicate timestamps accepted, overwritten, rejected, or aggregated?
• Can historical corrections be made safely and repeatably?
• Are updates transactional?
• Do queries use event time, ingestion time, or both?
• Are rollups recomputed after a backfill?

InfluxDB’s documented design principles prioritize time-ordered writes and restrict some update and delete behavior to support write and query performance. That is an InfluxDB design choice, not a rule applying to every TSDB.

Are time-series databases good for mutable business data?

A TSDB is often a poor primary system of record for orders, accounts, inventory, permissions, or other mutable business entities. Those workloads may require frequent corrections, referential integrity, multi-row transactions, strong read-after-write behavior across entities, and complex relational joins.

Time-series storage is usually a better fit for append-heavy observations that are rarely updated. A hybrid architecture separates responsibilities:

Operational database:
  users, devices, assets, configuration, ownership

Time-series database:
  measurements, telemetry, metrics, readings, observations

Object storage or warehouse:
  long-term archive, large-scale analytics, training data

PostgreSQL without a specialized extension can be enough when volume is moderate, the application already depends on PostgreSQL, ordinary SQL and joins dominate, retention is simple, and the time-series table can be partitioned and indexed effectively. A timestamp column alone is not a reason to introduce a separate TSDB.

What are the main time-series database categories?

The following categories are more useful than a flat list of “best TSDBs,” because each category targets a different workload.

Category	Representative systems	Best-known strength	Main qualification
Monitoring-native TSDB	Prometheus	Metrics collection, PromQL, alerting, service discovery, and cloud-native monitoring	Not a universal event, sensor, log, or business-record database
Prometheus-compatible long-term metrics store	VictoriaMetrics	Large-scale metrics storage and multiple ingestion protocols	Product fit centers on observability and metrics
Purpose-built general TSDB	InfluxDB	Telemetry ingestion, retention, and time-based analysis	InfluxDB 1.x, 2.x, 3, Cloud, and other editions have substantial differences
PostgreSQL extension	TimescaleDB or Tiger Data	SQL, joins, PostgreSQL integration, and relational metadata	PostgreSQL operations and schema design still matter
SQL-oriented time-series engine	QuestDB	SQL-oriented high-frequency time-series workloads	Current cloud, licensing, and operational details require separate verification
Columnar analytical database	ClickHouse or Apache Pinot	Large analytical scans across time, events, and many dimensions	Broader analytical platforms rather than necessarily the simplest metrics backend
Managed cloud service	InfluxDB Cloud, Tiger Cloud, VictoriaMetrics Cloud, and other cloud services	Reduced operational burden and hosted scaling	Ingestion, storage, queries, egress, replicas, retention, and support must be modeled

When is Prometheus the right choice?

Prometheus is a strong choice when the workload is operational metrics and the team needs pull-based scraping, service discovery, PromQL, alerting rules, dashboards, exporters, Kubernetes integrations, or the broader Prometheus ecosystem.

Prometheus is not usually the right source of truth for arbitrary IoT history, large text payloads, mutable application records, high-integrity financial transactions, or data requiring frequent corrections. Prometheus’s storage documentation describes local storage and optional remote-storage integration. Teams needing long-term durability or high availability should design that remote-storage architecture rather than treating one local Prometheus disk as an unlimited archive.

When is VictoriaMetrics attractive?

VictoriaMetrics is attractive for organizations seeking Prometheus-compatible observability storage at substantial scale, long-term metrics retention, and managed or self-hosted ingestion from multiple metrics protocols. VictoriaMetrics is less suitable when the primary requirement is general relational SQL, complex joins, text-heavy event payloads, or mutable business records.

When is InfluxDB attractive?

InfluxDB is attractive for general telemetry, IoT, industrial measurements, application-generated data, and teams that value InfluxDB clients, ingestion protocols, retention, and time-window analysis. InfluxDB generations and editions should not be treated as interchangeable. InfluxDB’s current-generation documentation describes InfluxDB 3 as using Apache Arrow and object storage and supporting SQL and InfluxQL.

When is TimescaleDB or Tiger Data attractive?

TimescaleDB or Tiger Data is compelling when the team already uses PostgreSQL and needs SQL, joins, relational constraints, PostgreSQL tooling, or close integration between telemetry and transactional metadata. Self-hosted availability and managed-cloud pricing are separate questions: a self-hosted product can avoid a managed-service fee while still requiring compute, storage, backups, upgrades, and on-call work.

When is ClickHouse attractive?

ClickHouse or a similar columnar analytical database can be preferable when historical scans are large, SQL analytics are central, many dimensions must be queried, or time-series data must be combined with logs, events, and broader analytical datasets. The trade-off is that a columnar analytical platform may require more operational and query-planning expertise than a turnkey metrics product.

How should you choose a time series database?

Choose a time series database by measuring the workload before comparing product features. “Fast writes” or “fast queries” is not meaningful without the data shape, time range, grouping dimensions, concurrency, hardware, replication, and retention policy.

1. Classify the data. Decide whether the workload is infrastructure metrics, IoT or industrial telemetry, financial ticks, user activity events, geospatial data, real-time dashboards, historical reporting, or machine-learning feature generation.
2. Measure ingestion. Record average and peak samples per second, event size, batch size, number of writers, burst behavior, and expected backfill volume. Deploy storms, outages, reconnect storms, and device recovery can make peak ingestion much larger than average ingestion.
3. Measure cardinality and churn. Track active series, historical series, new series per hour or day, label dimensions, series churn, and maximum label length. Inspect producers for request IDs, UUIDs, full URLs, stack traces, user IDs, session IDs, and arbitrary query strings.
4. Define query targets. Set targets for dashboard queries per second, alert evaluation intervals, maximum acceptable latency, concurrent analysts, historical scan size, and whether queries may compete with ingestion.
5. Choose the query ecosystem. Pick PromQL for Prometheus-style metrics, SQL for relational integration and analysts, InfluxQL or Flux only when the relevant InfluxDB generation supports the required workload, and compatible query languages only after checking semantic differences.
6. Test relational needs. If the common query joins telemetry to customers, assets, service contracts, ownership, or geographic metadata, favor PostgreSQL/TimescaleDB or a broader analytical database unless denormalization is deliberate and maintainable.
7. Design the lifecycle. Decide how much raw data remains queryable at each age, whether older data is rolled up or tiered, whether object storage is acceptable, how backups work, and whether deletion is prompt and verifiable.
8. Test correctness. Define behavior for duplicates, late data, out-of-order writes, clock skew, time zones, timestamp precision, idempotent retries, corrections, deletes, and rollup recomputation.
9. Compare operations and total cost. Include ingestion, storage, compute, queries, egress, replicas, backups, object storage, support, observability, engineering time, and on-call effort.

Which database fits which workload?

Primary requirement	Likely shortlist	Why	Important check
Infrastructure metrics, scraping, PromQL, and alerts	Prometheus or a Prometheus-compatible backend	Native fit for labeled monitoring metrics and the Prometheus ecosystem	Retention, high availability, remote storage, and active-series growth
PostgreSQL, SQL, joins, and relational transactions	PostgreSQL or TimescaleDB/Tiger Data	Relational integration and familiar SQL operations	Partitioning, indexes, PostgreSQL capacity, and update behavior
General telemetry, sensors, and retention policies	InfluxDB or another general-purpose TSDB	Purpose-built ingestion and time-window analysis	Product generation, query language, late data, and cost model
Large scans across events and many dimensions	ClickHouse or another columnar analytical engine	SQL analytics, columnar compression, and vectorized scans	Operational complexity, ingestion semantics, and transaction requirements
Managed operations	Managed InfluxDB, Tiger Cloud, VictoriaMetrics Cloud, or a verified cloud alternative	Hosted infrastructure, scaling, backups, and support options	Usage-based costs, region, egress, retention, replicas, SLA, and support

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

How much can managed time-series databases cost?

Managed pricing is volatile and depends on region, plan, retention, usage, replicas, queries, egress, and support. The following figures are the pricing signals documented for the requested August 16, 2026 snapshot and should be rechecked immediately before publication; the current date in the research dossier is August 18, 2026.

Service	Pricing signal in the dossier	What the price does not answer by itself
InfluxDB Cloud Serverless	Usage-based pricing page lists $0.0025/MB data in, $0.012 per 100 query executions, $0.002/GB-hour storage, and $0.09/GB data out; a free plan is available for learning and prototyping.	Actual monthly cost depends on ingestion volume, query executions, stored data, egress, free-plan limits, retention, and plan requirements.
Tiger Cloud	Pricing page lists metered compute, actual storage, compute starting at $30/month on the Performance plan, storage at $0.177/GB-month, and Scale plan compute starting at $36/month.	High-availability replicas, I/O boost, tiered storage, support, region, and workload size can add charges.
VictoriaMetrics Cloud	Product page shows single-node pricing from $225/month and cluster pricing from $1,300/month under the listed example capacities and one-month retention.	The examples are capacity-specific; active series, retention, deployment type, replicas, and other usage conditions determine the actual bill.

Exact current pricing for QuestDB Cloud, ClickHouse Cloud, AWS Timestream, Grafana Cloud, and Google or Azure managed services was not verified in the research dossier. Those services should not be assigned prices without checking their current official pricing pages.

Self-hosted Prometheus and self-hosted TSDBs may avoid managed-service charges, but self-hosting still requires infrastructure, backups, replication, upgrades, security, monitoring, disaster recovery, and capacity planning. “Open source” or “self-hosted” does not mean free to operate.

What production design mistakes cause the most trouble?

Unbounded labels

Symptom: Memory use, index size, or active-series count grows unexpectedly.

Cause: A producer uses request IDs, user IDs, raw URLs, UUIDs, stack traces, session IDs, or arbitrary query strings as metric labels.

Recovery: Identify the growing label, stop or relabel the producer, expire affected data if necessary, replace unbounded dimensions with bounded dimensions, and send unique details to logs, traces, or event payloads.

Unbounded maximum-resolution retention

Keeping every raw point forever increases storage, query, backup, and egress costs. Define raw retention, rollup resolution, archive policy, and deletion policy before production ingestion.

Averaging away meaningful behavior

Average latency can hide a small but serious group of slow requests. Preserve minimum, maximum, average, count, and distribution information such as histograms or quantiles when spikes and tail latency matter.

Confusing missing with zero

A sensor that did not report is not necessarily a sensor that measured zero. Schema, query, alert, and rollup logic should preserve the distinction between zero, missing, stale, and not reported.

Ignoring duplicate timestamps

A duplicate timestamp can mean a retry, two legitimate events at the same timestamp, a correction, a clock-resolution limitation, or conflicting measurements. Define whether the combination of series identity and timestamp is unique and verify the engine’s write semantics.

Ignoring clock skew and time zones

Store timestamps in UTC, preserve the original device timestamp when useful, record ingestion time separately, monitor clock drift, avoid using local wall-clock time as the only ordering key, and document precision and truncation behavior.

Putting rapidly changing metadata in series identity

Metadata such as firmware version can create unnecessary series churn when encoded as a label. Keep relatively stable dimensions in the series key and model changing attributes as fields or separate events when appropriate.

Assuming SQL means relational equivalence

A product can accept SQL syntax while differing substantially in transactions, joins, constraints, updates, indexing, isolation, query planning, data types, window functions, and time-zone semantics. Verify the exact engine and version against the application’s required behavior.

Treating retention as complete deletion

Retention deletion may not remove copies in WALs, backups, replicas, object-storage tiers, exports, materialized aggregates, or caches. Personal-data workloads need a deletion workflow that covers every copy and derived representation.

Comparing unnormalized benchmarks

Require any performance claim to disclose dataset size, series cardinality, sample width, compression settings, hardware, replication, query concurrency, cache state, ingestion protocol, retention policy, software version, and whether the result came from a vendor. A recent SciTSv2 research benchmark evaluates connection parallelism, batch ingestion, regularity, multivariate series, mixed workloads, and system metrics, illustrating why one throughput number cannot represent TSDB performance.

What should a time-series database production checklist include?

• Expected average and peak samples or events per second.
• Average and maximum payload size.
• Active series, historical series, label cardinality, and series churn.
• Allowed label values and a review process for new dimensions.
• Event-time, ingestion-time, and processing-time requirements.
• Late-data window and out-of-order write behavior.
• Duplicate, retry, correction, and deletion semantics.
• Raw retention, rollup intervals, tiering, and archive policy.
• Minimum, maximum, average, count, rate, histogram, or quantile requirements.
• Dashboard query concurrency and alert evaluation latency.
• Backup, restore, replication, disaster-recovery, and export tests.
• Security, private networking, authentication, and tenant isolation.
• Personal-data retention and complete-erasure requirements.
• Ingestion, storage, compute, query, egress, backup, support, and operations cost ceiling.
• A workload-specific benchmark using realistic regularity, cardinality, burstiness, late data, and query concurrency.

How should you benchmark candidates?

Benchmark candidates with the workload the production system will actually receive, not a synthetic stream chosen to favor one engine. Include regular and irregular sampling, realistic series churn, peak reconnect bursts, retries, late data, duplicate writes, historical backfills, dashboard queries, alert evaluations, and concurrent analytical scans.

Measure ingestion latency, sustained and peak throughput, active-series memory, storage consumed after compaction, query latency by time range, query concurrency, recovery time, backfill impact, deletion behavior, and total operating cost. Normalize hardware, replication, compression, cache state, retention, protocol, and software version before comparing results.

Bottom line

Choose a time-series database because the workload is time-oriented and operationally distinctive, not simply because a table has a timestamp. Prometheus is usually the natural starting point for scrape-based infrastructure metrics and PromQL alerting. TimescaleDB or PostgreSQL is attractive when SQL, joins, and transactions matter. InfluxDB and similar general TSDBs suit many telemetry workloads, while ClickHouse and other columnar systems are strong candidates for broad analytical scans.

The decisive design work happens before product selection: control cardinality, separate metrics from logs and events, define event-time and late-data behavior, plan retention and downsampling, decide how corrections and deletes work, and model the complete operating cost.

Frequently Asked Questions

Is a time series database faster than PostgreSQL?

A time series database is not universally faster than PostgreSQL; performance depends on schema, indexes, hardware, query range, ingestion pattern, concurrency, and retention. PostgreSQL can be the better fit for moderate volume, transactions, joins, and mutable application data, while a TSDB may be better for large append-heavy telemetry workloads and repeated time-window aggregations.

Is Prometheus the same as every other time series database?

Prometheus is not interchangeable with every other time series database. Prometheus is organized around labeled monitoring metrics, PromQL, scraping, service discovery, alerting, and recording rules, while general-purpose TSDBs may prioritize sensor data, arbitrary telemetry, SQL, long-term history, or broader analytics.

What is the difference between cardinality and data volume?

Cardinality is the number of distinct time series, whereas data volume is the number or size of stored samples and events. A workload can contain millions of samples in a small number of series or a smaller number of samples spread across millions of series; those patterns stress different resources.

Should request IDs be metric labels?

Request IDs should usually not be metric labels because request IDs are unbounded and can create a separate series for every request. Put bounded dimensions such as service, route template, method, and status class in metrics, and keep unique request details in logs or traces.

When is PostgreSQL enough for time-series data?

PostgreSQL may be enough when data volume is moderate, the data is tightly coupled to transactional entities, ordinary SQL and joins dominate, retention is simple, and partitioning and indexes provide acceptable performance. A timestamp column alone does not require a separate time series database.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.