What Is DCIM Software, and What Database Does It Use?

By Tiger Data Team

Published at Jul 10, 2026

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 (open source) and Tiger 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.

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 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.

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 (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 (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 (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)

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 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 and the guide to choosing 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 and the cluster sibling on long-term storage for Prometheus metrics.

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 and best Prometheus alternatives.

FAQ

What is DCIM software?

DCIM (Data Center Infrastructure Management) software tracks the physical assets, environmental conditions, and power consumption in a data center. Leading platforms include Sunbird dcTrack, Nlyte, Schneider EcoStruxure IT, Vertiv Environet Alert, and Device42. DCIM gives operations teams visibility into rack capacity, power usage effectiveness (PUE), temperature trends, and infrastructure asset inventory.

What database does DCIM software use?

Most DCIM platforms use a relational database as their primary backend. Sunbird dcTrack, for example, runs on PostgreSQL. For high-frequency sensor telemetry and power metrics, some teams extend their PostgreSQL instance with TimescaleDB or route telemetry to a separate time-series store. The choice depends on write volume and retention requirements.

How does DCIM software store sensor data?

DCIM platforms poll environmental sensors (temperature, humidity, airflow) and power monitors at regular intervals (typically 30 seconds to 5 minutes) and write each reading as a timestamped row. At scale, a 1,000-sensor deployment generates 60,000 to 120,000 rows per hour. Platforms store this data in a backend database - relational databases for asset context, and time-series optimized storage for the sensor streams themselves.

What is the best database for data center monitoring?

For data center monitoring, PostgreSQL extended with TimescaleDB handles both relational asset data and high-frequency sensor telemetry in a single system. InfluxDB works well for pure-metrics workloads where relational joins are not needed. Prometheus with remote write storage suits teams running infrastructure observability alongside DCIM data. The right choice depends on whether you need to join sensor data with asset records and how long you need to retain it.

How long does DCIM keep historical data?

Retention varies by platform and configuration. Most DCIM platforms support configurable retention, but long-term storage of raw sensor data (multi-year) is typically managed at the database layer rather than the application layer. With columnar compression in TimescaleDB or Tiger Cloud, multi-year retention for thousands of sensors is practical - a 3-year, 1,000-sensor dataset that would be 300 to 400 GB uncompressed compresses to roughly 15 to 40 GB.

Can DCIM data be queried with standard SQL?

If DCIM telemetry is stored in PostgreSQL or TimescaleDB, yes - standard SQL works for all queries, including time-range filters, aggregations, and joins to asset data. If telemetry is in a non-SQL system like InfluxDB 1.x, queries require Flux or InfluxQL, and joining to relational asset data requires application-level logic.

Can DCIM integrate with Grafana and Prometheus?

Yes. Most DCIM platforms offer API access to sensor and power data, which can be forwarded to a Prometheus endpoint or written directly to a PostgreSQL/TimescaleDB instance with a Grafana data source. Teams using this pattern visualize DCIM metrics alongside application and infrastructure observability data in a unified Grafana dashboard.

What is PUE and how is it calculated from DCIM data?

PUE (Power Usage Effectiveness) is total facility power divided by IT equipment power. A PUE of 1.0 is theoretical perfection; industry average is around 1.5 to 1.6; hyperscale data centers typically achieve 1.1 to 1.3. DCIM platforms calculate PUE continuously from power telemetry. In SQL, PUE can be computed with a continuous aggregate over a power_readings table, pre-aggregating hourly or daily totals for facility and IT power separately.

How do I store years of DCIM telemetry without running out of disk space?

Columnar compression is the most practical answer. TimescaleDB's Hypercore columnar storage compresses time-series data by 90 to 95% by exploiting temporal locality - adjacent rows in the same time window tend to have similar values, which compresses efficiently. A dataset that would occupy 300 to 400 GB uncompressed typically fits in 15 to 40 GB. Pair compression with a data retention policy to automatically drop chunks older than your required retention window.

Is DCIM only relevant for hyperscale data centers?

No. DCIM tools are widely used at mid-size colocation operators, enterprise data halls (500 to 5,000 rack units), and even large manufacturing facilities with on-premises server rooms. The database scaling problem - where sensor volume outgrows vanilla PostgreSQL's query performance - typically emerges at the 200-500 sensor level with 12 months or more of retention, which is well within mid-market DCIM deployments.

Should I use InfluxDB or PostgreSQL for DCIM sensor data?

PostgreSQL with TimescaleDB is the better fit when you need SQL joins between sensor telemetry and asset data, when your DCIM platform already runs on PostgreSQL, or when you want a single database for both operational and analytical data. InfluxDB is a reasonable choice for pure-metrics workloads without relational join requirements. Note that community reports suggest migration between InfluxDB 1.x and 2.x/3.x APIs carries operational risk on long-running deployments.