Database

Database configuration lives in the heads of the two engineers who set things up originally. When someone asks 'what engine is the analytics DB running?' or 'what's the replication topology?', the answer is 'SSH in and check.' Nobody has a written inventory of which databases exist, what they store, or how they're configured.

None — AI cannot assess database health, plan migrations, or optimize configurations because no formal record of database existence or purpose is available.

Database information exists in scattered Confluence pages, onboarding docs, and README files. Someone wrote up the production Postgres cluster two years ago, but the staging MySQL instance was never documented. An engineer looking for connection strings checks Slack history first. Configuration details are partially written down but never in one place and rarely current.

AI could potentially search documentation for database mentions, but cannot reliably determine which databases are active, their current configurations, or their relationships to services because the scattered records lack consistency and currency.

Databases are documented in a standard template in the internal wiki. Each database entry covers engine type, version, schema purpose, owning service, connection parameters, and backup policy. Engineers update these records when provisioning new databases. However, the records are static documents — they don't reflect real-time size, performance, or configuration drift.

AI can look up database purpose, ownership, and intended configuration from documentation, but cannot verify whether the documented state matches the actual running state or detect configuration drift.

Database records live in a CMDB or service catalog with discrete fields: engine, version, cluster topology, schema name, owning service, SLA tier, backup frequency, and retention policy. An engineer can query 'show me all PostgreSQL databases owned by the billing team running version 14 or below' and get an accurate, current result. Records are updated as part of provisioning and change management workflows.

AI can query the database inventory for migration planning, audit compliance, and dependency analysis. Cannot yet auto-detect schema changes or correlate database performance metrics with application behavior because performance telemetry isn't linked to the catalog records.

Database records are formal entities in an infrastructure ontology. Each database has validated relationships to dependent microservices, schema migration history, replication topology, performance baselines, and compliance classifications. An AI agent can ask 'which production databases have schemas modified in the last 30 days that serve PCI-scoped services and are running below their IOPS baseline?' and receive a precise, structured answer.

AI can autonomously plan database version upgrades, predict capacity needs based on growth trends, flag schema changes that risk breaking dependent services, and generate migration runbooks for routine operations.

Database records are self-documenting living entities. When a new database is provisioned, its schema, configuration, ownership, and compliance classification register automatically. When replication topology changes, the catalog updates within seconds. Performance baselines recalculate continuously. The database inventory is a real-time digital twin of every storage system in the infrastructure — never stale, never incomplete.

Can autonomously manage the full database lifecycle — provisioning, schema evolution, performance tuning, failover planning, and decommissioning — with real-time awareness of all dependencies and constraints.

Ceiling of the CMC framework for this dimension.