Connection Saturation
pg_views: pg_stat_activity, pg_settings
Full detection logic, thresholds, and guided fixes ship in the product.
Book a demo →Overview
Postgres allocates a backend process per connection. Each backend uses ~5–10 MB of memory and a file descriptor. At high connection counts, Postgres spends increasing time managing locks, shared memory, and backend overhead rather than executing queries. Above ~200 connections, performance typically degrades even without lock contention.
More critically, once connections reach max_connections, new connection attempts receive an error immediately—breaking the application. insightral fires this rule when connection usage exceeds 80% of max_connections, giving time to act before saturation.
The correct long-term fix is a connection pooler (PgBouncer in transaction mode), not increasing max_connections, which just defers the problem.
See this rule in action
Full detection logic, thresholds, and guided fixes ship in the product. The licensed agent runs this check — and all others — continuously against your database, surfaces findings with AI explanations, and surfaces a guided remediation path inside the dashboard.
Book a demo →Common False Positives
- A superuser connection from pg_dump or a monitoring agent counts toward max_connections — reserve connections via superuser_reserved_connections (default 3).
- Short-lived spikes during deployment rollouts where old and new pods briefly coexist — this is transient and not actionable.
Connection Saturation — and 100+ more checks — in the licensed product
Full detection logic, thresholds, and guided fixes ship in the product.
Book a demo →Last updated: 2026-05-13 · View the rule library