---
title: "What Is DCIM Software, and What Database Does It Use?"
description: "What database powers DCIM software? How DCIM platforms store environmental, power, and asset telemetry, and where time-series PostgreSQL fits."
section: "Data Center & Infrastructure Telemetry"
---
> **TimescaleDB is now Tiger Data.**
Data center infrastructure management software tracks physical assets, environmental conditions, and power consumption across every rack in a facility. If you searched "dcim database," you may want a DCIM tool recommendation. But you may also be asking a sharper question: what database sits beneath a DCIM platform, and is it the right one for the workload? This article covers both.
A DCIM platform generates five types of data, two of which (environmental sensor telemetry and power telemetry) are high-frequency time-series streams that benefit from a database with time-based partitioning and columnar compression. Standard relational databases handle asset inventory and configuration data well. The telemetry layer is where vanilla PostgreSQL, without extension, starts to show query degradation beyond a few hundred million rows. [TimescaleDB](https://www.tigerdata.com/timescaledb) (open source) and [Tiger Cloud](https://www.tigerdata.com/cloud) (managed) extend PostgreSQL with hypertables and Hypercore columnar storage to handle that volume without requiring a separate non-SQL database.
## What is DCIM software? An introduction for infrastructure engineers
Data center infrastructure management (DCIM) software tracks the physical assets, environmental conditions, and power consumption across a data center facility. It gives operations teams a live view of rack positions, PDU outlet draw, temperature sensor readings, and capacity headroom - all in a single operational platform.
The DCIM tools category includes both purpose-built platforms and broader IT asset management systems with DCIM modules. When evaluating DCIM tools, the database layer matters as much as the platform features - specifically how sensor telemetry is stored and queried at scale. The leading platforms infrastructure engineers encounter are:
- **Sunbird dcTrack** and **Power IQ** - dcTrack manages asset and capacity planning; Power IQ focuses on power and environmental monitoring. Sunbird is one of the more widely deployed DCIM platforms at mid-size colocation operators and enterprise data halls.
- **Nlyte DCIM** - a platform used at enterprise and service provider scale, with strong capacity planning and change management modules.
- **Schneider Electric EcoStruxure IT** - Schneider's DCIM offering, tightly integrated with APC UPS and PDU hardware. Often deployed in facilities already standardized on Schneider power infrastructure.
- **Vertiv Environet Alert** - Vertiv's monitoring platform, also hardware-coupled, with a focus on thermal and power alerting.
- **Device42** - takes a broader IT asset management approach, with DCIM capabilities layered in. Strong at discovery and dependency mapping.
These platforms share a common architecture: a web UI for operations, an API for integrations, a relational database for asset records and configuration, and a time-series data layer for sensor readings and power metrics. The relational backend is usually PostgreSQL or Microsoft SQL Server. What varies is how each vendor handles the high-frequency telemetry, and that is where the interesting database question lives.
### What DCIM software is not
DCIM is not a hypervisor or workload scheduler. It does not manage compute allocation - that is the job of VMware vCenter, Kubernetes, or similar orchestration layers. DCIM sits one layer below: it tracks the physical chassis those workloads run on, the power they consume, and the environmental conditions around them.
It is also not a building management system (BMS), though data center teams integrate DCIM and BMS to get a unified view of cooling plant efficiency and power flow from utility feed to rack.
## The five types of data DCIM platforms generate
Not all DCIM data has the same storage requirements. Here is what DCIM actually writes and reads.
**1. Environmental sensor telemetry.** Temperature, humidity, differential pressure, and airflow readings from sensors mounted at the rack inlet, row end, and room level. Typical write frequency: every 30 to 60 seconds per sensor. A 1,000-sensor deployment generates 60,000 to 120,000 rows per hour. This is a time-series workload.
**2. Power telemetry.** Outlet-level watt readings from intelligent PDUs, UPS capacity and load, PUE (Power Usage Effectiveness) time-series, and branch circuit current. Write frequency is typically 1 to 5 minutes. Fewer data points than environmental sensors, but each row carries more columns (per-outlet power, voltage, current, apparent power). Also a time-series workload.
**3. Asset and inventory data** Rack positions, server configurations, cable connections, chassis serial numbers, and vendor details. Written infrequently - on change events, not on a polling schedule. Standard relational storage handles this well. A large enterprise data center might have 50,000 to 100,000 asset records; that is well within what any competent relational database manages without special treatment.
**4. Capacity metrics.** Rack utilization percentages, cooling headroom, power headroom, and floor space availability. These are derived and aggregated values, typically recalculated on a schedule (hourly or daily) rather than streamed in raw. Usually stored as materialized summaries alongside the raw data.
**5. Alert and event logs.** Threshold breach notifications, state changes (door open/close, PDU bank trip), and acknowledgment records. Event-driven, append-only writes. Volume is low compared to sensor telemetry - usually measured in thousands per day, not millions.
Types 1 and 2 drive the volume; types 3 through 5 drive the schema complexity. A DCIM database that handles both well needs time-series partitioning for the high-frequency streams and relational joins for the asset context.
## What database does DCIM software actually use?
DCIM platforms that generate high-frequency environmental and power telemetry benefit from a time-series database layer - specifically one that combines PostgreSQL compatibility with time-based partitioning and columnar compression. PostgreSQL is already the backend for platforms like Sunbird dcTrack. The question is whether that PostgreSQL instance is equipped to handle time-series data volumes at scale, or whether a purpose-built extension is needed alongside it.
The architectural picture most operations teams end up with looks like this:
- **DCIM application database** (PostgreSQL or SQL Server): stores asset records, rack diagrams, cable maps, and configuration. This is the operational database the DCIM UI reads and writes directly.
- **Time-series telemetry database**: stores sensor readings and power metrics. Some teams keep this in the same PostgreSQL instance. Others route it to a separate time-series store (InfluxDB, Prometheus remote write target, or a PostgreSQL instance extended with TimescaleDB).
- **Analytics and reporting layer**: dashboards in Grafana or the DCIM platform's built-in reporting module, reading from both.
Whether the telemetry lands in the same database as the asset data or a separate one depends on write volume and retention requirements - the two factors that most reliably predict when vanilla PostgreSQL starts struggling.
For related context on how infrastructure telemetry is structured across similar workloads, see our guide on [IIoT database requirements](https://www.tigerdata.com/learn/iiot-database-requirements).
## Five database requirements for DCIM telemetry storage
### Requirement 1: Sustained high-throughput writes
A 500-sensor deployment polling every 30 seconds generates roughly 60,000 rows per hour (about 1.4 million per day). That is not a burst - it is continuous. The database needs to handle this write rate without degrading read performance for dashboards that are also querying the same data in near-real time.
Databases that handle OLTP reads and writes at modest scale but lack time-based partitioning tend to see write latency creep as the table grows. Partitioning writes by time range keeps each chunk small enough to write efficiently.
### Requirement 2: Time-based partitioning
Without partitioning, a query asking "what was the average temperature in Row C over the last 7 days?" must scan the entire sensor table. At 500 million rows, that query does not complete in dashboard time.
TimescaleDB's hypertables partition data automatically by time range. A query spanning 7 days touches only the chunks that contain those 7 days, regardless of how much historical data exists.
`-- Create the table
CREATE TABLE env_readings (
time TIMESTAMPTZ NOT NULL,
sensor_id TEXT NOT NULL,
location TEXT,
temp_c DOUBLE PRECISION,
humidity_pct DOUBLE PRECISION
);
-- Convert to a hypertable, partitioned by time
SELECT create_hypertable('env_readings', by_range('time'));`
This is the minimal schema for environmental sensor telemetry. Add an index on (sensor_id, time DESC) for single-sensor history queries, and you cover the two most common DCIM analytics access patterns.
### Requirement 3: Columnar compression for long retention
Uncompressed, a 1,000-sensor deployment at 30-second polling for 3 years produces roughly 3.1 billion rows and 300 to 400 GB of data. Most DCIM teams want multi-year retention for trend analysis and compliance. Storing 400 GB of raw sensor readings on fast NVMe storage is expensive. With [Hypercore](https://www.tigerdata.com/docs/learn/columnar-storage/understand-hypercore) columnar compression in Tiger Data, the same dataset typically compresses to 15 to 40 GB - a 90 to 95% reduction - without losing data.
Teams that run DCIM telemetry in uncompressed PostgreSQL often find themselves purging historical data not because they don't need it, but because the storage cost becomes untenable. Compression lets you keep the history.
### Requirement 4: SQL-native joins across telemetry and asset data
The persistent argument for keeping DCIM telemetry in the same database as asset data is the join problem. Dashboards that show "power draw by rack" or "temperature trend for chassis X" need to join sensor readings to the asset record that tells you which chassis is in which rack position.
If the telemetry database is a non-SQL system (like raw InfluxDB 1.x), those joins require application-level merges or an ETL layer. PostgreSQL-native time-series storage (TimescaleDB or Tiger Cloud) handles the join in SQL, at query time, without a separate pipeline.
### Requirement 5: Continuous aggregates for PUE and capacity reporting
Power Usage Effectiveness (PUE) is total facility power divided by IT equipment power. PUE of 1.0 is theoretical perfection. Industry average sits around 1.5 to 1.6; hyperscale data centers typically achieve 1.1 to 1.2. DCIM teams calculate PUE continuously from power telemetry and report it hourly or daily to facilities management.
Recalculating PUE from raw rows on every dashboard refresh is expensive at scale. A continuous aggregate pre-computes the hourly rollup incrementally - only processing new rows since the last refresh.
`-- Source hypertable for power telemetry
CREATE TABLE power_readings (
time TIMESTAMPTZ NOT NULL,
sensor_id TEXT NOT NULL,
sensor_type TEXT NOT NULL, -- 'facility_power' or 'it_power'
location TEXT,
watts DOUBLE PRECISION
);
SELECT create_hypertable('power_readings', by_range('time'));
-- Continuous aggregate: hourly PUE rollup
CREATE MATERIALIZED VIEW pue_hourly
WITH (timescaledb.continuous) AS
SELECT
time_bucket('1 hour', time) AS bucket,
location,
SUM(CASE WHEN sensor_type = 'facility_power' THEN watts ELSE 0 END) AS facility_watts,
SUM(CASE WHEN sensor_type = 'it_power' THEN watts ELSE 0 END) AS it_watts,
SUM(CASE WHEN sensor_type = 'facility_power' THEN watts ELSE 0 END) /
NULLIF(SUM(CASE WHEN sensor_type = 'it_power' THEN watts ELSE 0 END), 0) AS pue
FROM power_readings
GROUP BY bucket, location;
-- Refresh the rollup on a schedule so it stays current
SELECT add_continuous_aggregate_policy('pue_hourly',
start_offset => INTERVAL '3 hours',
end_offset => INTERVAL '1 hour',
schedule_interval => INTERVAL '1 hour');`
`The refresh policy keeps this view current on the `schedule you set, processing only new rows since the last refresh. (Real-time aggregates - which also merge the latest raw rows at query time - are disabled by default in TimescaleDB 2.13 and later; enable them if you need freshness between refreshes.) Grafana queries the view instead of the raw table, and PUE dashboard panels respond in milliseconds rather than seconds.
One design note: the view stores facility_watts and it_watts alongside the pue ratio. If you later stack a coarser rollup (daily, weekly) on top, recompute PUE from those two columns rather than averaging the stored pue - averaging a ratio of sums gives the wrong answer.
For more on continuous aggregates and time-series downsampling patterns, see our guide on [time-series downsampling](https://www.tigerdata.com/learn/time-series-downsampling).
## Where Tiger Data fits in a DCIM stack
Tiger Data (creators of TimescaleDB) builds a PostgreSQL-based time-series database designed for the kind of high-frequency sensor workloads that DCIM generates. It is not a DCIM platform and does not replace one. It is the database layer that a DCIM platform's telemetry backend can run on.
Two deployment options:
[**TimescaleDB**](https://www.tigerdata.com/docs/)** (open source)** - the PostgreSQL extension, self-hosted. Install it on the same PostgreSQL instance your DCIM platform already uses, or run it as a dedicated telemetry database alongside the DCIM application database. Full SQL, full ecosystem compatibility, no additional licensing cost.
[**Tiger Cloud**](https://www.tigerdata.com/cloud)** (managed)** - the fully managed cloud service. Usage-based pricing with independent compute and storage scaling. Suitable for teams that want managed PostgreSQL with time-series capabilities without operating the database themselves.
[**TimescaleDB Enterprise**](https://www.tigerdata.com/timescaledb-enterprise) (now accepting early-access requests) - Enterprise-grade, commercially licensed TimescaleDB for your self-managed infrastructure.
Where Tiger Data is the right fit:
- Deployments with more than 200 sensors and more than 6 months of retention where query latency on the raw table is already noticeable
- Teams routing multi-site DCIM telemetry into a central analytics database
- Infrastructure engineers who want to query DCIM sensor data with standard SQL alongside application and operational data
- Observability stacks using Prometheus with a remote write adapter, where DCIM metrics are one input among many ([see Prometheus alternatives](https://www.tigerdata.com/learn/prometheus-alternatives))
Where Tiger Data is not the right fit:
- Single-site deployments with fewer than 200 sensors and retention under 6 months - standard PostgreSQL handles this without extension
- Fully managed cloud DCIM SaaS deployments where the vendor controls the backend database and you have no access to it
- Teams whose DCIM vendor provides adequate built-in analytics for their needs and who have no requirement to join DCIM data with external systems
SAKURA Internet, a leading cloud and internet service provider, uses Tiger Data to store and query infrastructure telemetry at scale. Their use case - high-frequency metrics from a large distributed infrastructure - mirrors the pattern DCIM teams encounter when sensor counts grow. See the [SAKURA Internet case study](https://www.tigerdata.com/case-studies/sakura-internet) for the architecture details.
## InfluxDB vs. PostgreSQL-native time series for DCIM data
InfluxDB has historically been the default recommendation for infrastructure monitoring time-series data. For DCIM telemetry, it has genuine strengths and some real limitations worth knowing.
InfluxDB works well for DCIM when: write throughput for sensor streams is the priority (particularly with InfluxDB's line protocol); the team already has Grafana wired up via Flux or InfluxQL; and the workload is pure metrics with no relational join requirements.
InfluxDB creates friction when: telemetry needs to join with asset data (you end up maintaining two databases for one DCIM deployment); when the team is on a long-running deployment and faces the 1.x-to-2.x/3.x API migration - community reports suggest this carries real operational risk, and DCIM systems often run 5 to 10 years with minimal change; and when teams migrating from on-premises DCIM to cloud discover that InfluxDB Cloud Serverless's object-storage-first architecture behaves differently from self-hosted InfluxDB 1.x.
PostgreSQL-native time series (TimescaleDB) has the edge when: you need a single database for both asset records and telemetry with standard SQL joins; you want to use pg_stat_statements, logical replication, or existing backup tooling; or your DCIM platform already runs on PostgreSQL (like Sunbird dcTrack) and extending that instance is lower overhead than adding a second database system. Choosing Tiger Cloud (managed TimescaleDB) removes the burden of self-hosting.
For a broader look at how these options compare across use cases, see [the best time-series databases compared](https://www.tigerdata.com/learn/the-best-time-series-databases-compared) and the guide to [choosing an IoT database](https://www.tigerdata.com/learn/how-to-choose-an-iot-database).
## When to add a time-series layer to your DCIM stack
The decision comes down to write volume and retention.
**Stay with standard PostgreSQL if:**
- Fewer than 200 sensors
- Retention under 6 months
- Dashboard query times are acceptable today
- No requirement to join DCIM data with other operational datasets
**Add TimescaleDB to your existing PostgreSQL if:**
- You are hitting query latency on the raw sensor table at current data volume
- Retention requirements exceed 12 months and storage costs are climbing
- Your team knows SQL and wants to avoid learning a new query language
- Your DCIM platform already runs on PostgreSQL and you want to keep one database system
**Move to Tiger Cloud if:**
- Multi-site telemetry centralization with high aggregate write rates
- You want managed PostgreSQL with time-series capabilities and no DBA overhead
- You are running Prometheus remote write from your monitoring stack alongside DCIM metrics and want them in one queryable store
**Evaluate InfluxDB if:**
- Pure metrics workload with no relational join requirements
- Team has existing expertise with InfluxQL or Flux and is on a stable InfluxDB version
- You do not need SQL compatibility for cross-database analytics
**Evaluate Prometheus with remote storage if:**
- DCIM metrics are one input alongside infrastructure observability (Kubernetes node metrics, application metrics, DCIM sensor data)
- You already operate a Prometheus-based stack and want to extend retention without replacing it
For teams already running Prometheus, see our article on [data center power monitoring](https://www.tigerdata.com/learn/data-center-power-monitoring) and the cluster sibling on [long-term storage for Prometheus metrics](https://www.tigerdata.com/learn/prometheus-long-term-storage).
## Grafana, Prometheus, and the DCIM observability stack
Most operations teams that run modern DCIM don't rely solely on the DCIM platform's built-in charts. They route sensor and power metrics into Grafana via a Prometheus remote write pipeline or a direct PostgreSQL data source, alongside application and infrastructure observability data.
A common stack looks like this:
- **DCIM platform** scrapes sensors on its polling schedule, writes to its application database
- **Prometheus scrape adapter** or export pipeline forwards DCIM metrics to a Prometheus endpoint
- **TimescaleDB with Prometheus remote write** provides long-term storage beyond Prometheus's 15-day default retention
- **Grafana** queries both the DCIM application database (for asset context) and the time-series store (for telemetry history)
That gives you a single Grafana dashboard showing rack temperature, application latency, and PDU power draw in one view, with one query interface.
GPU workloads are pushing this further. High-density GPU racks run hotter than standard compute, which means higher write frequencies from thermal sensors and tighter alerting thresholds. Teams running GPU clusters in colocation facilities need DCIM telemetry in their infrastructure observability stack, not siloed in a standalone DCIM tool.
For more on Prometheus-based observability patterns, see [data center telemetry database](https://www.tigerdata.com/learn/data-center-telemetry-database) and [best Prometheus alternatives](https://www.tigerdata.com/learn/prometheus-alternatives).