At a glance
Connections In Use is the live count of active and idle backend connections held against the Supabase Postgres instance right now. Every Supabase tier ships with a hard max_connections ceiling set by the compute add-on, so this raw count is the denominator behind pool-saturation alerts. Read it next to Supavisor Pool Saturation % to know how much connection headroom you have left before new requests start queuing or failing.
What it tracks
The card reports the number of connections currently open against the database, grounded in thedetail: Connections In Use for the selected period. It is a real-time (RT) snapshot, not an average, so it reflects the instant the dashboard is read.
Postgres exposes one row per backend in pg_stat_activity; the count here is the total of those rows (active plus idle plus idle-in-transaction). On Supabase this number lives under a tier-bound max_connections cap that scales with the compute add-on, and most app traffic should arrive through the Supavisor pooler rather than opening direct connections. A steadily climbing count at flat traffic is the classic signature of a connection leak (clients opening but never releasing), while a sudden jump usually means a traffic burst or a misconfigured client opening direct connections instead of going through the pooler.
Reconciling against the source
Confirm the live count directly in Supabase withSELECT count(*) FROM pg_stat_activity; in the SQL Editor or psql, and compare against the ceiling with SHOW max_connections;. Supabase Studio → Reports → Database also charts active connections over time. A momentary difference from the card is expected because the card is a point-in-time RT sample and the counts move continuously.