AWS RDS PostgreSQL Monitoring

The RDS Monitoring Challenge

Amazon RDS is the most popular managed PostgreSQL service in the world, and for good reason: automated backups, patching, and failover remove enormous operational burden. But that convenience comes with a trade-off in observability. You cannot SSH into an RDS instance. You cannot install OS-level agents. You cannot read the PostgreSQL log files directly from disk. Even certain system catalog views are restricted or behave differently than on self-hosted PostgreSQL.

AWS provides CloudWatch metrics and Performance Insights to fill the gap, but these tools have significant limitations for day-to-day database work. CloudWatch metrics are aggregated at 1-minute or 5-minute intervals, so short-lived spikes vanish before you can see them. Performance Insights provides wait-event analysis and top SQL breakdowns, but its query-level detail is limited compared to pg_stat_statements and its retention maxes out at 2 years on the paid tier (most teams only use the free 7-day window).

MonPG bridges these gaps. It connects to your RDS instance using a standard PostgreSQL connection (the same way your application connects), queries the full set of catalog views and extensions that RDS makes available, and delivers the query-level, table-level, and index-level metrics that CloudWatch and Performance Insights simply do not provide.

How the MonPG Collector Works with RDS

The MonPG collector is a single Go binary that you run in your VPC — typically on an EC2 instance, in an ECS task, or as a Kubernetes pod. It connects to your RDS endpoint over the private network, authenticates with a dedicated monitoring user, and snapshots catalog views every 30 seconds.

Setup in Three Steps

• Create a monitoring role. Grant pg_monitor to a dedicated read-only user. This role can read statistics but cannot modify data or configuration.
• Enable pg_stat_statements.Add the extension to your RDS parameter group's shared_preload_libraries. RDS supports this natively — no reboot is required if the parameter group is already configured.
• Run the collector. Point the collector at your RDS endpoint with the monitoring credentials. Metrics appear in your MonPG dashboard within seconds.

The collector automatically detects that it is connected to an RDS instance and adjusts its behavior accordingly. It skips OS-level metrics that are unavailable on managed services and uses the RDS instance identifier for display names instead of hostnames.

CloudWatch Metrics Integration

While MonPG collects most metrics directly from PostgreSQL catalog views, certain infrastructure-level metrics are only available through CloudWatch. MonPG integrates with CloudWatch to pull:

• CPU utilization — correlated with query activity so you can identify which queries drive CPU spikes.
• FreeableMemory and SwapUsage — early warning when your instance is under memory pressure.
• ReadIOPS / WriteIOPS — correlated with pg_stat_statements block read/write counts to map I/O back to specific queries.
• NetworkReceiveThroughput / NetworkTransmitThroughput — useful for detecting replication bottlenecks on read replicas.
• DatabaseConnections— the CloudWatch view of connection count, cross-referenced with MonPG's per-database connection breakdown from pg_stat_activity.

This integration requires an IAM role or access key with read-only CloudWatch permissions. MonPG never writes to or modifies your AWS resources.

RDS Log Collection

On self-hosted PostgreSQL you can tail the log file. On RDS, logs are only accessible through the rds.download_db_log_file_portion API or CloudWatch Logs. MonPG's collector uses the RDS API to stream log entries, parse them, and feed them into the log insights pipeline.

This gives you structured analysis of:

• Slow query log entries (with duration and query text)
• Lock wait events and deadlocks
• Connection rejected errors
• Autovacuum activity and wraparound warnings
• Checkpoint timing and performance

You configure log collection frequency in the MonPG dashboard — the default is every 10 minutes, which balances freshness with API call costs.

Performance Insights: Useful but Not Enough

AWS Performance Insights is a valuable tool for understanding database load at the wait-event level. It answers the question "what is my database waiting on?" — CPU, I/O, lock waits, IPC, and so on. MonPG complements Performance Insights rather than replacing it:

• Performance Insights shows you wait events and top SQL by load. It is excellent for real-time triage.
• MonPG shows you query execution trends over time, index health, vacuum status, replication lag, and actionable recommendations. It is built for both triage and ongoing optimization.

Most teams use both: Performance Insights for live wait-event analysis during an incident, and MonPG for daily query review, index optimization, and capacity planning.

Aurora PostgreSQL Monitoring

Amazon Aurora PostgreSQL uses a fundamentally different storage architecture than standard RDS. The shared storage layer, automatic replication to six copies across three availability zones, and reader endpoint load balancing introduce monitoring considerations that do not exist on vanilla RDS.

MonPG handles Aurora-specific concerns out of the box: cluster-level aggregation across writer and reader instances, Aurora replica lag tracking (which behaves differently from standard streaming replication), and storage volume monitoring.

For a deeper dive into Aurora-specific monitoring, see our Aurora PostgreSQL monitoring guide.

RDS Multi-AZ and Read Replica Monitoring

Production RDS deployments typically use Multi-AZ for high availability and read replicas for scaling read workloads. MonPG monitors the full topology:

• Replication lag per replica. MonPG tracks byte-level lag and estimated seconds-behind for every read replica, alerting when any replica exceeds your configured threshold.
• Per-replica query analysis. Read replicas often run different query workloads than the primary. MonPG provides separate pg_stat_statements analysis for each replica so you can optimize read and write paths independently.
• Failover detection. When a Multi-AZ failover occurs, MonPG detects the role change and adjusts its metrics accordingly, without requiring manual reconfiguration.

Beyond CloudWatch: What MonPG Adds

Here is a summary of the metrics and features that MonPG provides on top of what AWS offers natively:

• Full pg_stat_statements history with delta calculation and trend analysis
• Index advisor with what-if impact estimation
• Unused and duplicate index detection
• Vacuum advisor with wraparound risk scoring
• Per-table and per-index cache hit ratio tracking
• Schema change detection and history
• Query regression alerts with before/after comparison
• Log insights with automatic categorization and pattern analysis
• Lock and blocking query visualization
• Wait event analysis correlated with query performance

Related Resources

• PostgreSQL Monitoring Guide — General PostgreSQL monitoring best practices.
• Aurora PostgreSQL Monitoring — Deep dive into Aurora-specific monitoring.
• Self-Hosted PostgreSQL Monitoring — Monitoring PostgreSQL on your own infrastructure.
• PostgreSQL Slow Query Monitoring — Track RDS query regressions, pg_stat_statements trends, and slow logs.
• How to Find and Fix Slow Queries — Complete guide to diagnosing slow queries with pg_stat_statements.
• PostgreSQL Index Optimization — When to add, remove, and rebuild indexes.