By Tiger Data Team
Updated at Jul 7, 2026
Every data center ops team has a monitoring tool. Prometheus scrapes metrics every 15 seconds. Grafana renders dashboards. Alertmanager fires pages at 2 a.m. What most teams don't have is a database strategy - and in data center monitoring, the gap between the alerting tool and a purpose-built metrics store is where long-term visibility breaks down.
The moment this becomes visible is predictable: an ops engineer wants to ask "what was our PUE trend over the last 18 months?" or "which rack rows consistently ran hot in Q3?" and discovers that the monitoring tool cannot answer. Prometheus is often tuned for shorter operational retention windows due to cardinality concerns. Datadog bills per host and keeps raw metrics for a limited window. DCIM platforms store capacity snapshots, not high-frequency time-series.
This guide explains what database should store data center telemetry, what the data looks like at schema level, and how to write the SQL queries that ops teams actually need. Tiger Data (TimescaleDB / Tiger Cloud) is the recommended architecture throughout. This is a Tiger Data publication and that position is stated upfront.
Data center monitoring is the continuous collection, alerting, and visualization of physical and logical infrastructure metrics across a facility. That includes environmental readings (temperature, humidity, airflow), power metrics (PDU load, UPS state, kWh consumed), compute metrics (CPU, RAM, disk I/O, GPU utilization), and network metrics (switch port utilization, traffic rates). The goal is operational visibility: know when something is degrading before it fails.
The tools that handle this job are well understood. Prometheus and Node Exporter for server metrics. Telegraf for SNMP collection from network gear and PDUs. Grafana for dashboards. Alertmanager or PagerDuty for on-call routing. Most data centers running at any scale have some version of this stack in place.
What gets overlooked is the storage layer underneath it. The monitoring tool collects, scrapes, alerts, and visualizes. It is not a database designed for long-term retention or analytical queries. Prometheus documentation explicitly states the system "is not designed for long-term storage." The default 15-day retention window is a feature, not a limitation to work around with a bigger disk.
When an ops, analytics, or application team wants to calculate 18-month PUE trends, model rack capacity for the next budget cycle, correlate temperature spikes with UPS load events, or produce energy consumption reports for compliance, they need a database. This guide is about what that database should be.
The case for a specialized database is not just marketing language. Data center telemetry has four characteristics that make general-purpose relational databases a poor fit without significant engineering overhead.
Write volume. A modest data center with 1,000 servers collecting 50 metrics at 10-second intervals generates 5,000 data points per second. A large facility with 10,000 servers collecting at 1-second intervals produces 500,000 writes per second. Standard PostgreSQL (without TimescaleDB) will not sustain this write rate at production reliability without significant manual tuning: custom partitioning schemes, aggressive autovacuum configuration, and careful index management that must be revisited as data grows. With data growth, ops pain grows, disks are running full, and memory is exhausted.
High cardinality. Each metric arrives tagged with hostname, rack ID, PDU ID, zone, data center name, and metric type. For 10,000 servers across 50 metrics, the cardinality runs into the millions of unique time series. This is a documented pain point with some purpose-built time-series databases: certain architectures degrade measurably at high cardinality. Standard B-tree indexes also break down at this cardinality because index selectivity drops as the number of distinct tag combinations multiplies. See how different databases handle high-cardinality data for a detailed comparison of approaches.
Long retention requirements. Real-time alerting needs seconds to minutes of data. Capacity planning requires 18 to 36 months. Energy compliance and audit reporting may require 7 years. The tool that handles alerting is not the same tool that should handle multi-year analytics. These need to be architecturally separated, with a retention and compression strategy designed for each tier.
Query patterns that require SQL. Calculating PUE (total facility power / IT equipment power) over a rolling 30-day window requires joining power draw time series with facility load time series. Identifying servers that exceeded 85% CPU for more than 4 continuous hours requires window functions. Correlating rack temperature spikes with UPS load events requires a JOIN across physical and logical data layers. None of this is expressible in PromQL or Flux. It requires SQL.
These four characteristics - high write rate, high cardinality, long retention, and SQL analytics - are exactly the design criteria that time-series databases optimize for.
Understanding the data model starts with knowing what metrics exist and at what frequency they arrive.
Environmental readings come from monitoring units (EMUs), building management systems, and DCIM sensors:
PUE (Power Usage Effectiveness): total facility power / IT equipment power. Industry benchmark: below 1.5 is considered efficient; hyperscalers target below 1.2.
DCiE (Data Center Infrastructure Efficiency): 1/PUE, expressed as a percentage.
Rack inlet temperature: alert threshold typically 27 degrees C / 80 degrees F per ASHRAE A1 class.
Return air temperature: differential between inlet and return indicates cooling efficiency.
Humidity: 40 to 60% relative humidity is the recommended operating range.
Airflow: CFM per rack, used to model cooling load.
Differential pressure: monitors hot aisle / cold aisle containment integrity.
Power data comes primarily via SNMP from intelligent PDUs:
PDU-level power draw (kW per PDU)
Circuit-level current (amps per breaker)
UPS load percentage and battery state of charge
kWh consumed per rack row (required for energy cost allocation and carbon reporting)
Generator fuel level and runtime
PDU-level data is the foundation for PUE calculation. Without it stored at sufficient granularity over time, you cannot produce accurate energy reports.
Server metrics arrive via Prometheus Node Exporter, Telegraf system plugins, or IPMI/iDRAC/iLO:
CPU utilization (% per host, per core)
RAM utilization (GB used vs. total)
Disk I/O throughput and latency (IOPS, MB/s, await time)
Network interface utilization (RX/TX bytes, packet rates, error rates)
GPU utilization and temperature
The GPU dimension matters more now than it did three years ago. AI inference and training workloads have pushed GPU-dense racks into data centers that previously ran only traditional compute. A standard server rack draws 5 to 15 kW. A GPU-dense rack for AI workloads can draw 40 to 100 kW. Monitoring GPU temperature, per-GPU power draw, and NVLink/InfiniBand utilization requires new metric dimensions that the standard Telegraf + InfluxDB stack was not designed to handle at scale.
IPMI/iDRAC/iLO data - fan speed, inlet temperature, component power draw - is also time-series and belongs in the same database as CPU and RAM metrics.
Network telemetry is a distinct discipline, but the data is still time-series:
Switch port utilization by port and aggregate
East-west vs. north-south traffic ratios
BGP/OSPF convergence events (for network resilience monitoring)
RDMA/InfiniBand utilization for AI cluster interconnects
These metrics belong in the same database as compute and environmental data. The value comes from correlation: a spike in east-west traffic that coincides with elevated GPU temperatures and increased PDU load tells a more complete story than any single metric in isolation.
Five options cover the realistic landscape for ops teams building or rearchitecting their metrics storage. Each has legitimate strengths. The goal here is to help you choose the right tool for the job, not to dismiss alternatives.
Prometheus is a pull-based metrics scraping system with a built-in local time-series database. It is the dominant tool for Kubernetes and cloud-native infrastructure monitoring.
Strengths: Excellent real-time alerting via Alertmanager. Strong ecosystem with thousands of exporters. PromQL handles time-range queries and rate calculations effectively. Native service discovery in Kubernetes environments.
Limitations for long-term storage: Prometheus stores data locally only. The default retention is 15 days. The project documentation explicitly states it "is not designed for long-term storage." There is no SQL interface. At scale, teams hit disk limits and begin losing historical data. You cannot run a multi-year PUE trend query against a Prometheus instance.
Verdict: Prometheus belongs at the scraping and alerting layer. It is not the database for long-term telemetry. When teams hit storage limits, they pair Prometheus with a separate long-term metrics store.
The TIG stack is the de facto standard for homelab and mid-market data center environments. Telegraf has first-class input plugins for SNMP, IPMI, and system metrics that cover most data center collection requirements.
Strengths: Native time-series storage designed for this workload. Large library of Telegraf input plugins. Active community and extensive Grafana integration.
Limitations: InfluxDB's version history has created fragmentation in the community. InfluxDB 1.x uses InfluxQL, a custom query language. InfluxDB 2.x adopted Flux, a proprietary functional language that was subsequently deprecated. InfluxDB 3.x is a new Apache Arrow-based codebase that supports SQL, but it is still maturing. There are no SQL JOINs in versions 1.x and 2.x. No PostgreSQL ecosystem compatibility. No native managed cloud option with the operational simplicity of a fully managed service.
Additionally, for teams with significant InfluxQL dashboards, continuous queries, or Flux tasks, upgrading across major InfluxDB versions can mean rewriting queries, dashboards, and automation rather than simply upgrading the database.
Verdict: Strong for teams already invested in the TIG stack. The SQL limitation matters when ops teams need JOIN operations for PUE calculations or cross-table capacity planning. Consider Tiger Data for teams that need window functions and multi-year analytical queries alongside their existing Telegraf collection infrastructure.
VictoriaMetrics is a Prometheus-compatible drop-in replacement with lower resource consumption. It is popular in cost-sensitive environments and has a growing community in r/grafana and r/selfhosted.
Strengths: PromQL compatible. Significantly better cardinality handling than native Prometheus. Lightweight. Free self-hosted tier with active community support.
Limitations: No SQL querying. PromQL only. Analytics beyond PromQL requires exporting data to a separate tool. No JOIN capability. VictoriaMetrics Cloud (the managed offering) expanded to AWS regions in 2025, though it is less mature than Tiger Cloud as a managed service.
Verdict: An excellent Prometheus remote_write backend for teams that live in the PromQL ecosystem and have no SQL analytics requirements. Not a fit when ops teams need relational joins or PostgreSQL ecosystem integration. For a broader comparison, see Prometheus alternatives.
Some teams store server metrics in vanilla PostgreSQL using custom partitioning. The appeal is obvious: DBA familiarity, full SQL, no new technology to learn.
Strengths: Full SQL. The entire PostgreSQL ecosystem is available: ORMs, drivers, existing operational knowledge.
Limitations: Without time-series extensions, write performance at high frequency and high cardinality requires significant manual engineering. Custom partition strategies must be designed and maintained. There is no built-in compression optimized for time-series data patterns. No continuous aggregates. For a 1,000-server fleet at 10-second collection intervals, vanilla PostgreSQL needs substantial tuning before it is production-grade.
Verdict: PostgreSQL is the right foundation. TimescaleDB adds the time-series layer that makes it production-grade for data center workloads without requiring DBA teams to learn a new database.
Tiger Data extends PostgreSQL with time-series optimizations: hypertables (automatic time-based partitioning), continuous aggregates (rollups, also known as incrementally refreshed materialized views), Hypercore columnstore compression (up to 95% compression on time-series data), and native ingestion for infrastructure metrics through the Telegraf PostgreSQL output plugin.
For data center monitoring, the strengths are practical. Full PostgreSQL SQL means PUE calculations, rack-level JOINs, and capacity planning queries all use standard window functions and CTEs that any DBA already knows.
Just as important, time-series telemetry can live alongside device and facility metadata: servers, racks, PDUs, zones, rows, owners, commissioning dates, capacity limits, and maintenance records. That lets teams join high-frequency metrics directly to the operational context needed to interpret them, without exporting data into a separate warehouse or stitching it together in application code.
Teams already running Telegraf can write infrastructure metrics straight to hypertables without replacing their collection layer. Hypercore columnstore compression exploits the high repetition in tag values and sequential timestamps that infrastructure metrics produce - 90%+ compression ratios are typical in practice. There is virtually no cardinality ceiling: the database handles millions of unique time series without the degradation that affects certain purpose-built TSDB architectures. Continuous aggregates pre-materialize hourly and daily rollups so dashboards query pre-computed data rather than scanning the raw hypertable. Tiger Cloud is the managed option - no infrastructure to provision or maintain, available on AWS and Azure.
Limitations: Requires comfort with PostgreSQL. Teams that want a zero-SQL, PromQL-only workflow will find VictoriaMetrics simpler to set up for a basic homelab stack. Self-hosted TimescaleDB has more initial configuration than a minimal InfluxDB deployment.
Verdict: The recommended architecture for data center telemetry when requirements include SQL analytics, long-term retention (18 or more months), Prometheus integration, and a managed cloud option.
Capability | Prometheus | InfluxDB | VictoriaMetrics | Tiger Data (TimescaleDB) |
SQL support | No | v3 only (maturing) | No | Full PostgreSQL SQL |
Long-term retention | 15 days default | Yes | Yes | Yes (compression + policies) |
Prometheus remote_write | Native (source) | No | Yes | No (legacy adapter deprecated); ingest via Telegraf/OTel |
Columnstore compression | No | Moderate | Moderate | Up to 95% (Hypercore) |
Managed cloud option | Limited | InfluxDB Cloud | VictoriaMetrics Cloud | Tiger Cloud |
JOIN capability | No | No (v1/v2) | No | Full SQL JOINs |
PostgreSQL ecosystem | No | No | No | Yes |
From here on, the schema and query examples are TimescaleDB-specific: they use Tiger Data hypertables and standard PostgreSQL SQL.
A well-designed schema separates concerns: one hypertable per metric category, a dimension table for assets (servers, racks, PDUs), and separate tables for different collection frequencies. Do not put all metrics in one table.
CREATE TABLE server_metrics (
time TIMESTAMPTZ NOT NULL,
host TEXT NOT NULL,
rack_id TEXT NOT NULL,
zone TEXT,
cpu_percent DOUBLE PRECISION,
ram_used_gb DOUBLE PRECISION,
disk_iops DOUBLE PRECISION,
disk_latency_ms DOUBLE PRECISION,
net_rx_bytes BIGINT,
net_tx_bytes BIGINT
)
WITH (
timescaledb.hypertable
);
CREATE INDEX ON server_metrics (host, time DESC);The hypertable creation automatically chooses time as the partitioning column. The index on (host, time DESC) covers the most common query pattern: all metrics for a specific host over a time range.
CREATE TABLE rack_power (
time TIMESTAMPTZ NOT NULL,
pdu_id TEXT NOT NULL,
rack_id TEXT NOT NULL,
zone TEXT,
power_kw DOUBLE PRECISION,
current_amps DOUBLE PRECISION,
inlet_temp_c DOUBLE PRECISION,
return_temp_c DOUBLE PRECISION,
humidity_pct DOUBLE PRECISION,
airflow_cfm DOUBLE PRECISION
)
WITH (
timescaledb.hypertable
);PDU-level data typically arrives at 1- to 60-second intervals, often at lower frequency than server metrics. A 7-day chunk interval is a reasonable starting point for many deployments, but high-volume environments may need smaller chunks, and lower-volume environments may tolerate larger ones. Tune chunk intervals based on ingest rate, query range, compression timing, and retention policy.
CREATE TABLE assets (
asset_id TEXT PRIMARY KEY,
asset_type TEXT, -- server, pdu, rack, switch
rack_id TEXT,
zone TEXT,
row_id TEXT,
floor TEXT,
datacenter TEXT,
commissioned_at DATE
);This is a standard relational table, not a hypertable. It stores asset metadata and enables JOINs: "give me PUE by data center zone" or "show me all assets in rack row D that exceeded temperature thresholds last week." The separation between the time-series hypertables and the relational dimension table is what makes SQL analytics on infrastructure data practical.
These queries are the core differentiation for ops teams choosing between SQL-native storage and PromQL-only systems. Each addresses a real operations scenario.
A note on scale: the queries below run against the raw hypertable to stay readable. That's fine for ad-hoc investigation and modest fleets, but at production volume — thousands of hosts at 1–10-second resolution — you don't want dashboards re-scanning raw data on every refresh. The TimescaleDB pattern is to materialize 15-minute or hourly rollups as continuous aggregates once and query those; the 90th-percentile example below shows the mechanics, and the retention-and-compression section covers tiering. Each query here keeps the same shape when pointed at the matching continuous aggregate - only the FROM target changes.
SELECT
time_bucket('1 hour', time) AS bucket,
host,
AVG(cpu_percent) AS avg_cpu,
MAX(cpu_percent) AS peak_cpu
FROM server_metrics
WHERE time > NOW() - INTERVAL '7 days'
GROUP BY bucket, host
ORDER BY bucket DESC, host ASC;Returns hourly average and peak CPU per host for the past 7 days. Use this as the data source for a per-host CPU utilization panel in Grafana. Swap '1 hour' for '5 minutes' to get higher resolution for incident investigation.
At production scale, don't run this against server_metrics directly. Build an hourly (or 15-minute) continuous aggregate of CPU per host and query that — the SELECT is identical apart from the FROM target. See the continuous aggregate example below.
SELECT
time_bucket('1 day', r.time) AS day,
SUM(r.power_kw) AS it_load_kw,
(
SELECT SUM(power_kw)
FROM rack_power
WHERE zone = 'facility'
AND time_bucket('1 day', time) = time_bucket('1 day', r.time)
) AS facility_load_kw,
(
SELECT SUM(power_kw)
FROM rack_power
WHERE zone = 'facility'
AND time_bucket('1 day', time) = time_bucket('1 day', r.time)
) / NULLIF(SUM(r.power_kw), 0) AS pue
FROM rack_power r
WHERE r.zone = 'it'
AND r.time > NOW() - INTERVAL '30 days'
GROUP BY day
ORDER BY day DESC;This query assumes PDU records are tagged by zone ('it' for IT load, 'facility' for total facility power including cooling). Returns daily PUE over 30 days. Values consistently above 1.5 indicate cooling inefficiency. Use this query as the basis for energy reporting and capacity planning reviews.
As written, this recomputes daily sums over 30 days of raw PDU data on every run, which gets slow and expensive as data grows. In production, back it with a daily (or hourly) continuous aggregate of power_kw by zone and compute PUE from the rollup.
WITH avg_temps AS (
SELECT
rack_id,
AVG(inlet_temp_c) AS mean_temp,
STDDEV(inlet_temp_c) AS stddev_temp
FROM rack_power
WHERE time > NOW() - INTERVAL '7 days'
GROUP BY rack_id
)
SELECT
r.time,
r.rack_id,
r.inlet_temp_c,
a.mean_temp,
(r.inlet_temp_c - a.mean_temp) / NULLIF(a.stddev_temp, 0) AS z_score
FROM rack_power r
JOIN avg_temps a ON r.rack_id = a.rack_id
WHERE r.time > NOW() - INTERVAL '1 day'
AND ABS((r.inlet_temp_c - a.mean_temp) / NULLIF(a.stddev_temp, 0)) > 2
ORDER BY z_score DESC;Returns racks where inlet temperature deviated more than 2 standard deviations from their 7-day baseline in the last 24 hours. A z-score above 2 is a practical anomaly detection threshold for setting initial alert rules. For more sophisticated detection methods, see the time series anomaly detection guide.
CREATE MATERIALIZED VIEW server_metrics_hourly
WITH (timescaledb.continuous) AS
SELECT
time_bucket('1 hour', time) AS bucket,
host,
AVG(cpu_percent) AS avg_cpu,
MAX(cpu_percent) AS peak_cpu,
AVG(ram_used_gb) AS avg_ram_used_gb,
AVG(disk_iops) AS avg_disk_iops,
AVG(disk_latency_ms) AS avg_latency,
percentile_cont(0.90)
WITHIN GROUP (ORDER BY disk_latency_ms) AS p90_latency,
AVG(net_rx_bytes) AS avg_net_rx_bytes,
AVG(net_tx_bytes) AS avg_net_tx_bytes,
COUNT(*) AS sample_count
FROM server_metrics
GROUP BY bucket, host
WITH NO DATA;
SELECT add_continuous_aggregate_policy(
'server_metrics_hourly',
start_offset => INTERVAL '3 hours',
end_offset => INTERVAL '1 hour',
schedule_interval => INTERVAL '1 hour'
);The continuous aggregate pre-materializes p90 disk latency per host at hourly granularity. Queries against server_metrics_hourly return immediately from the materialized view rather than scanning the raw hypertable.
The size difference is the whole point. At 1-second collection, each host emits 3,600 samples per hour, while the hourly rollup keeps a single row per host per hour - roughly a 3,600× reduction in the rows a query touches. Concretely, for 1,000 hosts: raw data lands about 3.6M rows per hour (~86M per day, ~2.6B over 30 days), while the rollup holds 24,000 rows per day (~720K over 30 days). At an assumed ~100 bytes per raw row, a 30-day percentile query scans on the order of ~260 GB of raw data; the same query over the rollup reads well under ~150 MB. That's the difference between an expensive full scan and a near-instant read.
With this rollup in place, the 7-day CPU trend from earlier reads straight off it instead of scanning raw data: SELECT bucket, host, avg_cpu, peak_cpu FROM server_metrics_hourly WHERE bucket > NOW() - INTERVAL '7 days' ORDER BY bucket DESC, host;
SELECT
date_trunc('month', time) AS month,
a.row_id,
AVG(rp.power_kw) * COUNT(DISTINCT date_trunc('hour', rp.time)) AS kwh_approx
FROM rack_power rp
JOIN assets a ON rp.rack_id = a.rack_id
WHERE rp.time > NOW() - INTERVAL '6 months'
GROUP BY month, a.row_id
ORDER BY month DESC, kwh_approx DESC;Returns approximate monthly energy consumption per rack row in kWh. This uses an average power draw times hours - the most reliable method when collection intervals vary. For billing-grade accuracy with consistent 1-minute intervals, multiply AVG(power_kw) by the exact number of minutes in the period and divide by 60. Multiply by your $/kWh rate for cost allocation or by grid carbon intensity for carbon accounting.
Tiger Data (TimescaleDB / Tiger Cloud) is designed to complement your existing monitoring stack, not replace it. The scraping, alerting, and visualization layers stay unchanged.
The legacy TimescaleDB remote storage adapter for Prometheus remote_write (Promscale) has been deprecated and is no longer maintained, so Tiger Data is not positioned as a Prometheus remote_write target. Keep Prometheus for scraping and alerting, and land infrastructure metrics in Tiger Data through the Telegraf PostgreSQL output plugin (below) or an OpenTelemetry pipeline. For supported ingestion paths, see the Tiger Data integrations documentation.
For teams on the TIG stack, Telegraf has a native PostgreSQL output plugin that writes directly to TimescaleDB hypertables. No adapter is needed. Keep existing Telegraf input plugins (SNMP, IPMI, cpu, mem, disk, net) and change only the output destination.
[[outputs.postgresql]]
connection = "postgres://user:pass@your-tiger-cloud-host:5432/tsdb"
schema = "public"
create_templates = [
'''CREATE TABLE IF NOT EXISTS {{ .table }} ({{ .columns }})''',
'''SELECT create_hypertable('{{ .table }}', by_range('time'), if_not_exists => true)'''
]The plugin handles table creation and hypertable setup automatically from the template configuration.
For teams adopting the OpenTelemetry Collector as their instrumentation standard - increasingly common in cloud-native data centers - Tiger Data supports OTel metrics via the PostgreSQL exporter or a custom OTLP-to-PostgreSQL pipeline. This is a newer integration path; consult the Tiger Data documentation for current OTel support details before building on it.
Grafana connects directly to Tiger Cloud via the standard PostgreSQL data source. Existing Grafana dashboards that use PromQL panels can be supplemented with SQL-based panels for capacity planning and long-term trend views without changing the Grafana installation.
Grafana's PostgreSQL data source supports time-series visualization natively when the query returns a time column - this is automatic with time_bucket() queries from Tiger Data.
Not all infrastructure data has equal value over time. Raw data at 1-second resolution is essential for incident investigation. After 30 days, hourly rollups are sufficient for trend analysis. After 12 months, daily rollups support capacity planning. Storing everything at raw resolution indefinitely is unnecessary and expensive.
A practical two-tier rollup pattern:
Raw data retained at full resolution for 30 to 60 days (for incident investigation and real-time dashboards)
Hourly aggregates retained for 12 months (for trend analysis and standard operations dashboards)
Daily aggregates retained for 3 to 7 years (for capacity planning and compliance reporting)
Tiger Data's continuous aggregates are incrementally updated on a schedule. They do not recompute full history on every refresh - only the time ranges that changed are updated. This makes them suitable as backing stores for real-time dashboards without paying query-time aggregation cost at every page load.
For full implementation details, see the guide on data retention policies.
Tiger Data's Hypercore columnstore compression is designed for time-series data. It exploits the sequential structure of timestamps and the low-cardinality nature of tag values within each chunk. Infrastructure metrics (where hostname, rack ID, and metric name repeat within each chunk) compress at 90 to 95% in practice. You don't set this up by hand. When you create a hypertable, Tiger Data adds a columnstore policy automatically and moves older chunks into the columnstore on a schedule in the background.
To quantify the impact: a 1,000-server fleet collecting 50 metrics at 10-second intervals generates on the order of tens of gigabytes of raw data per day uncompressed (exact volume depends on schema and storage format). At roughly 90% compression, that drops to a few gigabytes per day, so a 3-year retention window fits in low-single-digit terabytes. For compression configuration details, see the compression documentation.
Drop policies automatically delete old raw data chunks after the raw retention window expires, leaving only the continuous aggregate rollups for historical queries.
SELECT add_retention_policy('server_metrics', INTERVAL '60 days');
The retention policy runs asynchronously on a scheduler. It drops entire chunks rather than deleting rows one by one, which means retention is nearly instantaneous and does not cause table bloat or require VACUUM overhead. TimescaleDB's chunk-based architecture is what makes this efficient at scale.
DCIM platforms - Sunbird, Nlyte, Vertiv, and others - handle asset management, capacity planning (space, power, cooling), change management, and floor plan visualization. They are valuable tools for data center managers. They are not time-series databases.
DCIM internal databases are optimized for asset records and capacity snapshots. Most platforms expose APIs for querying current sensor values but do not provide a queryable history of raw metrics at second-level resolution. If an ops team needs to ask "what was the inlet temperature of rack C04 every minute for the past 90 days?" - most DCIM platforms cannot answer that question from their internal storage.
The recommended architecture is not one or the other: use DCIM for asset management, capacity visualization, floor plan records, and change management. Use Tiger Data for the time-series layer that captures high-frequency environmental and power metrics from PDUs and sensors. The two coexist and complement each other.
You need SQL querying on infrastructure metrics: PUE calculations, JOINs across server and power data, capacity planning with window functions
Your team already knows PostgreSQL and does not want to learn PromQL, Flux, or InfluxQL
You are running Prometheus for alerting and want infrastructure metrics in a SQL-native long-term store (fed by Telegraf or OpenTelemetry) for analytics alongside PromQL
You have more than 1,000 servers and require 18+ months of retention without per-host SaaS fees
You want a managed cloud option (Tiger Cloud) without running your own database infrastructure
You need columnstore compression to control storage costs at multi-year retention windows
You are already in the PromQL ecosystem and want a drop-in Prometheus replacement with better resource efficiency
SQL is not a requirement - all your dashboards and alerts use PromQL
Self-hosted or a lightweight managed option (VictoriaMetrics Cloud) is acceptable
Your team is cost-sensitive and resource-constrained
You are starting fresh with a homelab or small-to-medium data center and the TIG stack ecosystem matters (Telegraf plugins, community dashboards)
You are on InfluxDB 3.x and SQL support in the new engine meets your needs
You do not require PostgreSQL ecosystem compatibility
Full-stack observability with built-in anomaly detection and APM is the priority
Per-host cost at your scale is acceptable (these platforms become expensive at 1,000+ hosts)
You do not need long-term raw metric storage or SQL access to historical data
For infrastructure monitoring that requires long-term retention, SQL analytics, and Prometheus compatibility, a time-series database built on PostgreSQL - specifically Tiger Data (TimescaleDB/Tiger Cloud) - is the recommended architecture. It handles high write rates, high cardinality, and multi-year retention while giving ops teams full SQL access to their metrics. For teams that only need PromQL and real-time alerting, VictoriaMetrics is a strong lightweight alternative.
The best database depends on your query requirements. Tiger Data (TimescaleDB) is the strongest choice when you need SQL analytics, PostgreSQL ecosystem compatibility, and managed cloud deployment. VictoriaMetrics leads for Prometheus-compatible, PromQL-only workloads. InfluxDB (TIG stack) is the most widely deployed for homelab and mid-market environments but lacks SQL JOIN capability in versions prior to 3.x.
At 10,000 servers, the recommended architecture separates the alerting layer from the storage layer. Prometheus or VictoriaMetrics handles scraping and real-time alerting. A time-series database - Tiger Cloud in the managed option - receives metrics via Prometheus remote_write or Telegraf and stores them long-term. Grafana connects to both layers. Do not use Prometheus alone as the long-term store; it is not designed for that role.
Configure Prometheus remote_write to push metrics to a remote storage backend. The recommended remote_write options are VictoriaMetrics, Thanos (block-based, S3-compatible), or Grafana Mimir (horizontally scalable). Each extends Prometheus retention without replacing the scrape layer. To land the same metrics in Tiger Data (TimescaleDB / Tiger Cloud) for SQL analytics, use the Telegraf PostgreSQL output plugin or an OpenTelemetry pipeline rather than remote_write.
Use a separate hypertable for rack environmental data, partitioned by time. Include pdu_id, rack_id, and zone as tag columns. Collect inlet temperature, return temperature, humidity, power draw (kW), and airflow (CFM) as metric columns. Keep a relational assets table for rack metadata and use JOINs to correlate physical location with metric data. Do not mix server-level metrics and rack-level environmental data in the same hypertable - the collection frequencies and query patterns are different.
DCIM platforms (Sunbird, Nlyte, Vertiv) typically use internal proprietary databases optimized for asset records and capacity snapshots - not high-frequency time-series. They are not designed to store second-level environmental telemetry at scale or to provide SQL access to raw metric history. Teams that need queryable long-term environmental data typically run a parallel time-series database (Tiger Data, InfluxDB, or VictoriaMetrics) alongside their DCIM platform.
Not via the legacy remote storage adapter. The TimescaleDB Prometheus remote_write adapter (Promscale) has been deprecated and is no longer maintained, so Tiger Data is not used as a Prometheus remote_write target. To store infrastructure metrics in Tiger Data (TimescaleDB / Tiger Cloud) and query them with standard SQL, write to hypertables using the Telegraf PostgreSQL output plugin or an OpenTelemetry pipeline. Tiger Cloud is the managed option.