What This Table Is

The cmdb_ci_database table stores database configuration items within ServiceNow's Configuration Management Database (CMDB). These records represent database instances like Oracle, SQL Server, MySQL, PostgreSQL, and other database systems discovered through IT Operations Management (ITOM) or manually created by administrators. Each record captures essential database metadata including version, edition, cluster information, and operational status.

This table belongs to the CMDB module and supports the broader IT service management process by providing visibility into database infrastructure. Database CIs serve as critical components in dependency mapping, impact analysis during incidents, and capacity planning initiatives. The CMDB uses these records to understand application-to-database relationships and infrastructure dependencies across the enterprise.

The table extends cmdb_ci, inheriting standard CI fields like name, operational_status, and environment. Several specialized database CI types extend this table including cmdb_ci_db_ora_instance for Oracle databases and cmdb_ci_db_mssql_instance for SQL Server instances. Database CIs frequently have parent-child relationships with server CIs through cmdb_rel_ci relationship records.

Large enterprises typically maintain thousands of database CI records, with discovery tools creating the majority automatically. The table performs well at scale, but queries filtering on discovery-populated fields like version or edition can be expensive without proper indexing. Record volume grows steadily as database infrastructure expands, making lifecycle management and automated cleanup essential for maintaining CMDB health.

When You'll Script Against This Table

You'll most commonly script against cmdb_ci_database in Business Rules that trigger on discovery updates, Transform Maps that process discovery data, and Script Includes that support CMDB health reporting. Database CI records frequently appear in Service Mapping contexts where you're building or validating application topology. Scheduled Jobs often query this table for compliance reporting, vulnerability scanning integration, and automated lifecycle management.

Access to database CIs is controlled by standard CMDB roles (itil, cmdb_read, cmdb_write) with additional restrictions often applied through domain separation. Discovery service accounts require elevated access to create and update records, while application teams may have read-only access scoped to specific environments or business services.

  • Building dependency maps between applications and their database backends
  • Generating compliance reports for database versions and patch levels
  • Calculating database license costs based on instance type and hosting relationships
  • Automating incident assignment based on database CI ownership and support groups
  • Creating change approval workflows that consider database cluster relationships
  • Integrating vulnerability scanner results with database CI records for risk assessment
  • Building Service Mapping patterns that automatically discover database service dependencies

Table Gotchas

⚠️

The `tcp_port` field often contains multiple comma-separated values for clustered databases, breaking simple equality queries. Always use `.contains()` or split the values when filtering by port.

⚠️

Database CI names from discovery tools frequently include instance IDs or cluster suffixes, making exact string matches unreliable. Use `startsWith()` or regular expressions for name-based queries.

  • The version field is a string, not a version-aware field type, making version comparison logic complex and error-prone
  • Database CIs created by different discovery tools may have inconsistent edition values (e.g., 'Enterprise' vs 'ENT') requiring normalization logic
⚠️

Queries filtering on `install_status` without including `operational_status` often return unexpected results. Discovery tools may set these fields independently, creating inconsistent states.

  • The run_as_user field contains operating system usernames, not ServiceNow user references, causing confusion in access control scenarios
  • Large-scale queries joining database CIs with server CIs through relationships can timeout; use GlideAggregate with chunking for bulk operations
Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

No spam · Unsubscribe anytime

Related Tables

Database CIs inherit from cmdb_ci, gaining standard CI capabilities like lifecycle management, change tracking, and relationship mapping. This parent table provides essential fields for asset management integration and discovery correlation. The cmdb_rel_ci table connects database CIs to their hosting servers, creating the infrastructure topology that Service Mapping depends on.

You'll frequently join database CIs with cmdb_ci_server records to understand the complete hosting stack, and with cmdb_ci_appl records to map application dependencies. The cmdb_ci_service table often references database CIs as critical components of business services. For incident and change management workflows, database CIs connect to sys_user_group records through the support_group field, enabling automated assignment and escalation logic.

Discovery and inventory management scenarios require joins with cmdb_ci_computer to correlate database instances with their physical or virtual machine hosts. When building comprehensive asset reports, you'll often traverse relationships between database CIs and alm_asset records through the parent CI hierarchy, enabling license compliance and cost allocation reporting.