InvGate Asset Management now governs databases as assets. It discovers instances across five engines, flags the ones running versions their vendor no longer supports, maps what depends on them, and captures recorded evidence before a critical change to a database record is saved.
Databases have sat outside the asset record in most organizations, administered by whoever owns them and rediscovered during an audit. This article covers what InvGate Asset Management discovers, how support status and dependencies appear on that record, and what the evidence step captures when something changes.
We introduced these capabilities at ENVISION'26, our global user conference. Explore everything else we announced!
What InvGate Asset Management discovers
Discovery runs from the agent already installed on the host, which detects the database services running there and reports what each instance is and how it is configured. How it connects varies by engine: PostgreSQL and SQL Server are set up as Discovery Sources, while MySQL, Oracle, and MariaDB (coming soon) are collected without database credentials at all. Each discovered instance arrives as a Configuration Item holding:
- Engine and version.
- IP address and port.
- Uptime and architecture.
- The host server it runs on.
- The databases it hosts.
Records update on the agent's regular inventory cycle, so instances appear, move, and disappear from the inventory without anyone entering them by hand. A healthcare IT team running discovery before an audit can surface a four-year-old MySQL 5.7 instance nobody knew about, already past vendor support, in time to decommission it before the auditor arrives.
Lifecycle visibility with Atlas
Atlas fills in end-of-life (EoL) and end-of-support (EoS) status per engine version directly on the Configuration Item, so nobody cross-references vendor documentation one instance at a time. Coverage follows what each vendor publishes, so it varies by engine and version rather than spanning every release.
The payoff is planning instead of reacting. A university team managing 47 instances across three environments can sort by end-of-support date and see exactly what needs upgrading in the next twelve months, which turns a multi-week collection exercise into a filter.
Dependency mapping with CI connections
Databases participate in the same CI connections layer as the rest of the estate, alongside assets, people, cloud assets, and business applications. Five native types ship ready to use:
- Technical Owner.
- Commercial Owner.
- Security Auditor.
- Runs on.
- Stored In.
Two of them carry most of the weight for a database: "Runs on" links it to the asset or cloud asset hosting it, and "Stored In" links it to where it is stored. Every connection records a criticality, low, medium or high, and appears on the Related CIs tab of both profiles the moment it is created, so it is written once and read from either end. Organizations that name things their own way can add their own types from Settings.
Connections are declared, not inferred: a person records that this database carries that application, and that statement is what the map shows. Keeping it current is not manual: a change can fire an automation, and a connection whose other end disappears is cleaned up or flagged for review. The judgment stays with a person.
Change evidence on a governed change
Every change to a Configuration Item is already logged in "Activities," which records what changed. Governance adds what "Activities" leaves out: when it is enabled, a change to a critical property on a database configuration item triggers an evidence capture step, where the person making the change records the actual author, the effective date, and the reason behind it. Critical properties include status, owner, other native properties, and custom fields.
What that adds is specific. Activities cannot say why a change was made, who authorized it, or whether the person who edited the record is the same one who made the change in the real world, and those are the questions a security review asks months later. A DBA who reassigns ownership on a production instance supplies that context at the time, and the review reads the full account from the change history.
Conclusion
A database has a version, an owner, a host, a lifecycle, and a date after which nobody patches it. Governing it as an asset means discovery puts it on the record, Atlas marks its support status, CI connections shows what it carries, and the evidence step records who changed it and why.
All four work on the same record as the rest of the estate, so none of it runs as a separate exercise alongside Asset Management. You can run discovery against your own environment with a 30-day free trial, or talk to Sales to work through which engines and environments are in reach.
