A CMDB is a database that stores information about IT assets (configuration items) and the relationships between them.
A CMDB (configuration management database) is a database that stores information about an organisation’s IT assets - servers, applications, network gear, desktop computers - and, crucially, the relationships between them. Each entry is a configuration item (CI) with its own attributes, and each CI is linked to the things it runs on, depends on, or connects to. The relationship data is what separates a CMDB from a plain asset register: it answers not just “what do we own” but “what breaks if this goes down”.
What counts as a configuration item
A CI is any component worth tracking in its own right. Typical examples:
- Hardware CIs - servers, switches, firewalls, storage arrays, end-user devices
- Software CIs - applications, databases, operating systems, middleware
- Virtual and cloud CIs - virtual machines, containers, cloud instances and services
- Service CIs - the business services those components add up to, such as “email” or “invoicing”
Each CI carries attributes (name, version, environment, owner, location) and relationships (“runs on”, “depends on”, “is part of”). Deciding the level of detail is the first design decision: track every cable and the CMDB drowns in upkeep; track only servers and it cannot answer useful questions.
Relationships are the point
Consider a chain: the invoicing application runs on a virtual machine, which runs on a host in the server room, which connects through one switch. When that switch needs replacing, the CMDB tells you - before you touch anything - that invoicing goes down with it. That is impact analysis, and it is the core CMDB use case. The same data works in reverse for troubleshooting: when invoicing is slow, the CMDB shows every component underneath it worth checking. This is why CMDBs are a fixture of change management in larger IT organisations.
CMDB vs asset register vs ITAM
The boundary is purpose. An asset register serves ownership and money: who has each device, what it cost, when the warranty ends, what happens at disposition. A CMDB serves operations: technical configuration and dependencies, in support of changes and incidents. ITAM is the broader practice; a CMDB is one tool, used mostly by ITSM-driven teams. The two overlap on the hardware itself - the same server appears in both - but they record different facts about it. License entitlements and renewals, for instance, belong in software license management records, not in a dependency graph.
When a small team actually needs one
A CMDB pays off when you operate infrastructure other systems depend on and make changes that need impact assessment - your own servers, a production environment, anything with an outage cost. It does not pay off as a first system of record for a team whose estate is laptops, smartphones, and SaaS seats; those questions are about ownership and renewals, and the CMDB’s biggest failure mode - being populated once and never updated - hits hardest in teams without a change process to feed it. For that majority case, a current asset register beats a stale CMDB, and a tool like AMPthilly keeps one with owners, checkouts, documents, and audit history per asset, no dependency mapping required.
Related terms
- Software Asset Management - managing the software side of the IT estate
- Software License Management - where entitlements and renewals are tracked
- License Compliance - staying within the license terms you hold
- IT Asset Disposition - retiring hardware securely at end of life
- True-Up - the license reconciliation a vendor audit triggers