What a Metric Database Is
A metric database is a storage system purpose-built for numeric time-series data: measurements, counters, gauges, and histograms captured at regular or irregular intervals. Unlike general-purpose databases, it organizes data around a timestamp and one or more labeled dimensions, then optimizes for high write throughput, efficient compression, and fast range scans. Common choices include InfluxDB, Prometheus, TimescaleDB, and VictoriaMetrics, each trading off query flexibility, cardinality limits, and operational complexity in different ways.
More from this site
Keep reading the latest coverage
Teams reach for a metric database when relational stores become a bottleneck—either because the write volume overwhelms standard rows-per-second limits, or because analytical queries over large time windows run too slowly to be useful in dashboards and alerting pipelines.
Core Data Model
Most metric databases share a common conceptual model. A metric is a named measurement, such as cpu_usage or http_requests_total. Each data point consists of a timestamp, a numeric value, and a set of key-value pairs called labels or tags that describe the context—host name, region, service version, and so on.
Tags vs. Fields
Tags are indexed and used for filtering and grouping; they are low-cardinality by design. Fields hold the actual measurement value and are not indexed. Keeping this distinction clear prevents common performance pitfalls, especially in systems where high-cardinality tags cause unbounded series growth.
Granularity and Downsampling
Raw metrics often arrive at second or sub-second intervals. Metric databases typically store data at multiple granularities, automatically rolling up high-resolution points into lower-resolution aggregates—such as 1-minute or 1-hour averages—to reduce storage cost while preserving trend visibility.
When to Use a Metric Database
The strongest use cases share a pattern: continuous numeric data, time-aware queries, and a need for rapid aggregation. Common domains include:
- Infrastructure monitoring: CPU, memory, disk I/O, and network throughput across fleets of servers.
- Application performance monitoring (APM): request latency, error rates, and throughput per endpoint.
- Business metrics: daily active users, conversion rates, or revenue counters that feed operational dashboards.
- IoT and sensor pipelines: telemetry from devices reporting temperature, pressure, or voltage at scale.
A metric database is the wrong choice when your primary workload involves complex joins, transactional integrity, or frequently updated individual records. Those patterns fit relational or document stores better.
Design and Operational Considerations
Choosing a metric database means weighing several trade-offs that shape long-term reliability and cost.
| Attribute | Detail | Context |
|---|---|---|
| Write throughput | Millions of points per second in optimized engines | Critical for high-cardinality environments |
| Storage efficiency | Columnar compression, delta-of-delta encoding | Reduces cost for long retention windows |
| Query language | SQL-like, PromQL, or custom expression languages | Affects analyst onboarding and tooling |
| Cardinality limits | Soft or hard caps on unique series | Prevents runaway storage growth from noisy tags |
| Retention policies | Automatic downsampling and expiration | Balances query performance against storage budget |
Schema Design Pitfalls
The most common mistake is treating labels like relational columns and adding high-cardinality values—request IDs, user emails, or arbitrary strings—as tags. This explodes the number of unique series and degrades both write and query performance. A better approach is to pre-aggregate or move high-cardinality attributes into a separate index or log system.
Integration with Observability Stacks
Metric databases rarely operate in isolation. They feed into visualization layers like Grafana, alerting systems such as Alertmanager, and log or trace backends that together form an observability pipeline. The database's ability to serve fast range queries and instant aggregates determines whether dashboards load in seconds or minutes, and whether alerts fire within the intended SLO window.
Choosing the Right System
No single metric database fits every team. Prometheus excels in pull-based Kubernetes environments with a rich ecosystem of exporters. TimescaleDB extends PostgreSQL, making it a natural fit for teams that already rely on SQL. InfluxDB offers a SQL-like query language and strong clustering story, while VictoriaMetrics prioritizes resource efficiency at extreme scale. The decision should follow from your expected write volume, query patterns, retention requirements, and the skills of the team that will operate it.