Getting Started

Add a Database — AWS RDS for PostgreSQL

Step-by-step: connect an Amazon RDS PostgreSQL instance to MonPG, including security group + Parameter Group setup.

If you've onboarded an RDS instance to anything in the last few years, the steps will feel familiar. The only sticking point on AWS specifically is whether your master user can CREATE EXTENSION. Usually yes; if you've locked it down, you may need to elevate first.

Before you start

You need PostgreSQL 12 or higher (we recommend 14+). The master user you set when you created the instance — typically postgres, but the name is whatever you typed. The instance must be reachable from the internet, or you need to switch to agent mode and run our collector inside your VPC.

One more pre-flight thing: your VPC security group needs to allow MonPG's hosted-fleet egress range on the PostgreSQL port. Open RDS in the AWS console, find your instance, go to Connectivity & security, click into the VPC security group, and add an inbound rule:

Type: PostgreSQL
Protocol: TCP
Port: 5432
Source: 20.107.185.112/29
Description: MonPG hosted fleet

(If you've changed your DB port from 5432, swap it. The /29 covers all of MonPG's hosted-fleet egress; we publish it on this page when it changes.)

Verify pg_stat_statements is preloaded

RDS ships pg_stat_statements in the default Parameter Group's shared_preload_libraries. Verify by connecting and running SHOW shared_preload_libraries;. If it's not there, your Parameter Group has been customized at some point — edit it, add pg_stat_statements, save, then reboot the instance. SPL changes are restart-bound.

Onboard via the UI

Go to app.monpg.app, click Setup, pick Amazon Web Services. Choose Hosted — Auto-setup unless you specifically need to run the SQL yourself.

The form asks for host (your endpoint, looks like prod-db.abc123.eu-west-1.rds.amazonaws.com), admin username (your master user), admin password, and SSL mode. RDS enforces SSL by default; leave it at require.

Click Test connection. We probe the cluster, list databases, list installed extensions, return a consent summary. You pick which databases to monitor (subject to your plan's database quota). You can optionally tick the safe extensions to install — pgstattuple for bloat metrics, hypopg for hypothetical-index simulations, pg_buffercache for cache pressure analysis. All three are pure DDL, no SPL or restart.

Click Provision monitor role. Done in five to fifteen seconds depending on database count.

Optional: CloudWatch logs

If you want Log Insights you'll need an IAM role MonPG can assume with logs:GetLogEvents and rds:DescribeDBLogFiles. Full walkthrough on Log Insights AWS setup — there's a JSON policy you can copy verbatim and a trust-policy template with the right ExternalId.

Also make sure RDS is exporting PostgreSQL log to CloudWatch (Modify instance → Log exports → check "PostgreSQL log"). Without this, RDS writes logs to an internal store nothing can reach.

Verify it's working

Within thirty seconds the server appears in the header dropdown with a green dot. Within a minute the Queries page has data. If the dot is gray or "Disconnected" persists past two minutes, the cause is almost always the security group rule above. Double-check it. If it's correct, see RDS-specific troubleshooting.

Aurora

Aurora's onboarding is the same as RDS for the writer endpoint. Reader endpoints have a separate flow because they expose their own pg_stat_statements per-instance. See the dedicated Aurora guide.