Schema change detection automatically identifies modifications to your database schema such as added or removed tables, altered columns, new or dropped indexes, constraint changes and reports them as activity events in the Hybrid Manager (HM) console.
Schema change detection operates in two stages:
Schema collection: The EDB Postgres AI Agent periodically polls the monitored database and sends the current schema state to the beacon server. The poll frequency is controlled by
schema.poll_interval(default:1m).Change detection: The beacon server compares each incoming schema snapshot against the previously stored version. When differences are found, the server emits schema change events to the activity service (
accm-server), which records them in the HM Activity Log.
A 10-minute grace period applies after a database is first registered. During this window, newly discovered tables aren't reported as changes, and this prevents the initial schema ingestion from generating a flood of "table added" events.
Detected change types
- Table added or removed
- Column added, removed, or modified (data type, nullability, default value)
- Index added or removed
- Constraint added or removed
- Table type changed
Enabling schema change detection by deployment type
Schema change detection requires schema collection to be active. How you enable it depends on your deployment type:
On-prem databases
For databases monitored with the on-prem EDB Postgres AI Agent, schema collection must be explicitly enabled in your beacon-agent.yaml. Set schema.enabled to true for each node entry:
provider: onprem: clusters: - resource_id: "<cluster_resource_id>" nodes: - resource_id: "<node_resource_id>" dsn: $DSN schema: enabled: true poll_interval: 1m
Once schema collection is enabled, change detection is automatic on the server side irrespective of deployment type, and no additional configuration is required. If schema.enabled isn't set or is false, no schema data is collected and changes can't be detected.
HM-managed clusters and external CNPG clusters
For HM-managed Postgres clusters and external CloudNativePG clusters, the EDB Postgres AI Agent runs as a sidecar container alongside the database. Schema collection is enabled by default.
External cloud databases such as RDS
For external cloud-hosted databases monitored via the EDB Postgres AI Agent, follow the same configuration as on-prem databases. Set schema.enabled: true in the EDB Postgres AI Agent configuration for the relevant node entry.
Limitations
- The EDB Postgres AI Agent detects changes to tables and columns while running. Changes to views or procedures aren't detected until you restart the EDB Postgres AI Agent.
- Schema change detection relies on the activity service (
accm-server) being available to receive events. See Activity service unavailability for details.
Activity service unavailability
Schema change events and other beacon telemetry are delivered to the platform through the activity service (accm-server). If the activity service is degraded or unavailable, events fail to send from the EDB Postgres AI Agent. This is expected platform behavior and not a product defect. Event delivery resumes automatically once the activity service recovers.
Note
No schema change data is lost on the monitored database itself. Only the reporting of detected changes to the HM console is delayed until the activity service is available again. The EDB Postgres AI Agent continues to collect schema snapshots, and the server detects and reports changes once the activity service recovers.