AWS Database Insights for EC2 PostgreSQL: Setup and Limits

For infrastructure teams that use the AWS console as a shared operational surface, the practical attraction is clear: database load, waits, query activity and host telemetry can be investigated in one product rather than separately correlating operating-system monitoring, PostgreSQL statistics and managed-database dashboards. The caveat is equally important. This is a monitored PostgreSQL deployment that requires an agent, database-side configuration, IAM permissions and an explicit cost review—not a switch that makes self-hosted databases equivalent to RDS or Aurora.

What AWS actually added​

AWS says self-managed PostgreSQL support is available in all AWS Commercial Regions. The feature places eligible PostgreSQL instances on EC2 alongside RDS and Aurora in the Database Insights fleet and instance experiences. The core signals AWS describes include:

• DB Load, intended to show the level of database activity over time.
• Wait-event analysis, which can help distinguish CPU pressure from sessions stalled on a particular resource or activity.
• Query-level statistics, including Top SQL data.
• Host metrics, so database symptoms can be examined with system-level context.
• Execution plans and logs, subject to setup and permissions.

That combination can shorten the first phase of an incident investigation. A team seeing slow application requests can start with load and wait composition, identify expensive or frequently active SQL, then compare the database view with host behavior rather than immediately choosing between disconnected tools.

AWS’s technical material describes frequent database telemetry collection: pg_stat_activity is sampled every second for DB Load and wait events, while pg_stat_statements is polled every 60 seconds for Top SQL. Those are meaningful differences. Session-state data can reflect a rapidly changing problem, while query-ranking data should be treated as a periodically refreshed view, not a second-by-second trace of every statement.

The scope must not be overstated. The documented self-managed support currently covers PostgreSQL on Amazon EC2 only. It does not establish support for self-managed MySQL, SQL Server, Oracle, or other engines, and it does not establish support for databases hosted outside EC2. Organizations with mixed database estates should therefore treat this as a PostgreSQL-specific addition to their monitoring design, not as a reason to retire cross-engine monitoring arrangements.

Useful integration, not full managed-service parity​

The most persuasive aspect of the feature is workflow consistency. Teams already familiar with Database Insights for RDS or Aurora can use the same general fleet-and-instance approach for an EC2 PostgreSQL server. That matters for centralized operations: it can reduce dashboard switching and gives database, platform and application staff a common starting point during performance triage.

But core workflow consistency is not full feature parity. AWS explicitly identifies two current gaps for self-managed instances:

• Performance Analysis Reports are not supported.
• Lock Analysis is not supported.

The Lock Analysis omission deserves attention for PostgreSQL operators. Lock contention can be central to an outage or degradation, especially during schema changes, long transactions or competing batch work. Wait-event information may still show that sessions are blocked or delayed, but teams should not assume the dedicated managed-database lock investigation experience is present. Existing PostgreSQL lock-query procedures, application diagnostics and runbooks remain necessary.

Likewise, a Performance Analysis Report workflow cannot be assumed to exist for an EC2-hosted PostgreSQL incident. The service can provide important raw and aggregated diagnostic signals, yet the operational process around those signals still needs to account for the missing tools.

There is also an account-and-region design limitation. AWS says self-managed instances do not appear in Fleet View when Database Insights cross-account, cross-Region mode is enabled. For a centralized operations group, that means a fleet layout that works well for managed RDS and Aurora resources may not provide the same unified view of EC2 PostgreSQL. Teams should test their actual account structure before promising a single global console to stakeholders.

AWS documentation also says a Database Insights fleet cannot monitor more than 500 DB instances and recommends filters that keep a health view below that limit. The general documentation states the cap, although the self-managed setup material does not separately explain how self-managed entries are counted. Large organizations should therefore treat 500 as an important planning constraint and validate their intended fleet arrangement rather than assuming EC2 PostgreSQL is exempt.

Deployment prerequisites shape the architecture​

This is not remote, agentless database monitoring. AWS documents several prerequisites that define where it can be used:

1. The database must be PostgreSQL 14 or later.
2. PostgreSQL must run on Amazon EC2.
3. The CloudWatch agent must run on the same host as PostgreSQL.
4. The EC2 instance needs an IAM role authorized to publish the required metrics and logs.
5. Remote database monitoring is unsupported.

The same-host requirement has direct design consequences. A team cannot simply point a collector from a separate management server at a PostgreSQL endpoint and expect this implementation to work. Every monitored database host needs local agent lifecycle management: installation, configuration rollout, upgrades, service monitoring and troubleshooting.

That local dependency also changes the division of responsibility. The database administrator needs to prepare PostgreSQL statistics and credentials; the cloud or platform team needs to operate the agent and IAM role; finance or observability owners need to govern CloudWatch ingestion. The tool can centralize visibility, but it distributes implementation tasks across the teams that own the host, database and AWS account.

For teams administering their cloud environment from Windows workstations or working in mixed Microsoft and Linux operations groups, the important takeaway is that Database Insights is an AWS and PostgreSQL operational workflow, not a replacement for host configuration management. The documented capability should be evaluated against the actual EC2 PostgreSQL hosts, identity model and incident process in use. The supplied material does not establish broader operating-system or non-EC2 database coverage, so deployment assumptions should be verified before standardizing on it.

PostgreSQL configuration and least privilege are central​

AWS directs users to enable pg_stat_statements, the PostgreSQL extension that collects execution statistics. Without it, the Top SQL portion of the experience cannot deliver the intended query-level view. This is an explicit database configuration dependency, not merely an agent option.

AWS also directs users to create a dedicated monitoring user and grant it the built-in pg_monitor role. That is the right security posture for production deployments: observability should use a purpose-specific, least-privilege identity rather than a superuser credential borrowed for convenience.

Execution-plan collection raises the permission bar in a targeted way. If an organization wants Database Insights to capture plans through EXPLAIN, the monitoring user must also receive appropriate access to the relevant schemas and tables. That permission deserves a deliberate review because query plans can expose table names, query structure and potentially sensitive aspects of an application’s data model. It is not enough to decide that execution plans would be helpful; security and data owners should decide whether the required read access is appropriate for the monitoring identity.

A sensible rollout sequence is therefore:

• Confirm the PostgreSQL version and EC2 placement meet the documented boundary.
• Decide which hosts and databases need monitoring first.
• Enable and validate pg_stat_statements under a change-controlled database procedure.
• Create the dedicated monitor account with pg_monitor rather than using an administrative login.
• Make an explicit decision on whether execution-plan permissions are justified.
• Attach only the IAM permissions needed for the agent to publish telemetry.
• Establish ownership for agent updates, failed telemetry and credential rotation.

This is also a useful moment to review logging policy. Database logs can be diagnostically valuable, but log collection increases cost exposure and can introduce retention and data-handling concerns. The right configuration for a development system may not be the right configuration for a production system carrying regulated or sensitive workloads.

Sampling details and the host-metrics question​

The documented one-second pg_stat_activity sampling and 60-second pg_stat_statements polling give operators a clear sense of the database-side collection cadence. Host-metric timing is less clear in the available evidence.

AWS’s technical blog describes host telemetry at a 15-second interval. However, an independent hands-on test published the same day observed a 30-second hostmetrics/opentelemetry interval in the expanded effective agent configuration. The two observations may concern different telemetry streams, versions or configuration behavior, but the supplied material does not resolve the discrepancy.

The practical response is not to build alerting, capacity calculations or post-incident expectations around either interval until a team has inspected the effective configuration and observed its own emitted metrics. For most performance triage, the availability of host context is more important than whether a particular series is exactly 15 or 30 seconds apart. For short CPU spikes, bursty I/O or tightly tuned alerts, however, the distinction can be material.

Independent testing does provide a limited indication that the feature operates as described. One tester used PostgreSQL 16.15 on a t3.micro and reported that DB Load, wait events and Top SQL appeared in the console. In an idle 300-second measurement, the agent consumed roughly 140 MB of resident memory and about 2.5% of one CPU core.

Those numbers should not be adopted as a production sizing rule. They come from one small, idle test environment. Agent overhead can plausibly differ with database activity, instance size, agent release, enabled logs and telemetry volume, but the supplied evidence does not quantify those differences. A staged deployment with host-level before-and-after measurement is the more defensible approach.

Retention is straightforward; cost is workload-dependent​

Self-managed Database Insights does not use the Standard or Advanced modes associated with other Database Insights coverage. AWS documents 15 months of retention for collected metrics. That can be useful for comparing recurring seasonal behavior or investigating a regression that appeared months earlier.

Logs follow a separate model: agent-collected logs are governed by the configured CloudWatch Logs retention. In practice, metric retention and log retention should be decided together. Keeping metrics for 15 months while retaining verbose database logs for a much shorter period may be entirely sensible, but it means that old performance trends might not have the corresponding raw log context.

AWS says there is no separate feature charge for self-managed Database Insights itself. That should not be read as zero-cost monitoring. Standard CloudWatch OpenTelemetry metric ingestion pricing and CloudWatch Logs charges apply. AWS lists OpenTelemetry metric ingestion at $0.50 per GB, and pricing varies by Region. Actual spending depends on the uncompressed volume of metric payloads and the amount of log data collected; the supplied information does not offer a workload-specific cost estimate.

This makes a pilot valuable for financial as well as technical validation. Enable a representative configuration on a small number of systems, observe metric and log ingestion, and project from measured usage rather than assuming the service’s lack of a separate fee makes its ongoing cost negligible. Log verbosity and retention should be reviewed especially carefully, since they can materially alter the bill and the data-governance profile.

Where this is most useful—and where caution is warranted​

The feature is best suited to organizations with self-managed PostgreSQL on EC2 that already use CloudWatch and want database and host signals in a more unified operational interface. It should be particularly useful when the first questions in an incident are familiar ones: Is the database busy? What is it waiting on? Which SQL is prominent? Is the host under pressure?

It is less suitable as the sole answer when an estate depends on engines other than PostgreSQL, databases outside EC2, dedicated lock-analysis workflows, or a cross-account and cross-Region fleet dashboard that must include every database class. Those needs are not met by the documented self-managed capability today.

The right conclusion is measured. CloudWatch Database Insights now provides meaningful observability for a specific self-managed PostgreSQL deployment model, with fast session sampling, query statistics and host context that can improve investigation workflows. Adoption should proceed as an engineering change: validate version and placement, use least-privilege database and IAM roles, test telemetry cadence, measure agent overhead, and forecast metric and log ingestion costs. Teams that do that can gain a useful PostgreSQL monitoring path without mistaking it for universal database support or full managed-service feature equivalence.