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 CMDB stands for and where it comes from
CMDB stands for configuration management database. The term comes from IT service management (ITSM) frameworks such as ITIL, where the CMDB is the central store that underpins the configuration management process. In practice it acts as a data warehouse for your IT environment: every managed component is recorded as a configuration item, and the database holds both the item’s attributes and its links to everything around it. That second half - the relationships - is what makes it a CMDB rather than a spreadsheet of kit. It is the same distinction that separates a CMDB from broader IT asset management, which we come back to below.
What counts as a configuration item
A configuration item (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. A good rule is to scope by use case, not by asset - if a class of CI never shows up in an incident, a change, or an audit, leave it out.
What a CMDB record looks like: an example
A CMDB entry is more structured than a line in a spreadsheet. A single CI record typically carries a name or ID, a CI type (server, application, database, network device, cloud resource), a status, the environment it runs in (production, staging, development), an owner, and technical fields such as IP address or version - and then, on top of all that, its relationships.
A worked example makes it concrete. A CI named app-prod-01 is typed as an application, sits in production, is owned by the payments team, and carries three relationships: it runs on a virtual machine, depends on a payments database, and is part of the checkout service. Query that one record and you see, in a single view, everything the checkout service leans on. Multiply that across hundreds of CIs and you get a service map - the tree of dependencies behind each business service, which is what most CMDB tools draw for you.
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, which is the basis of root-cause analysis. This is why CMDBs are a fixture of change management and incident management in larger IT organisations.
Why CMDBs go stale - and how teams keep them current
A CMDB is only as good as its freshness, and the classic failure is well known: it is populated once during a project, then drifts out of date as the estate changes around it. Practitioners often put it bluntly - a CMDB does not fail at launch, it fails a few months later, when no one can say who owns a given record. Two things keep it honest. The first is automated discovery: tooling that scans the network and cloud accounts and updates CIs as infrastructure changes, so the database is not fed by hand. The second is clear ownership: every CI needs a named owner responsible for its accuracy, and the most critical CIs get re-checked on a schedule. Without a change process feeding it, a CMDB goes stale fast - which is exactly why it suits teams with mature ITSM practices and rarely suits those without one.
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. Put simply, ITAM tells you what you own and what it costs, while a CMDB tells you how it is wired together and what breaks if you touch it. 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