shadcn.io is not affiliated with official shadcn/ui
PostgreSQL Connections Monitoring Block for Ark UI
A total bar of connections in use against max_connections, six application rows with stacked Active, Idle and Idle in transaction bars and a role-limit tick, and the five longest-held connections of the chosen application.
Installation
Overview
See who holds the connections of a database and which application leaves transactions open, with this connections panel for React with Ark UI. It is Tuskgate, a connection monitor (made up) for PostgreSQL. A hairline frame with a plus mark on each corner opens with one bar for the connections in use against max_connections, split into Active, Idle and Idle in transaction. Under it six applications are rows of one radio group, each a stacked bar on a shared scale with a tick at its own role limit, a count against that limit and its share of all connections. Choosing an application lists its five longest-held connections below: pid, user, state, age and the last query in mono. The header names the application that holds the most idle-in-transaction connections, worked out from the counts. Guides draw the frame and its bands; the entrance is CSS only. For platform and database teams chasing pool exhaustion.
FAQ
How do I use my own counts?
Edit APPS at the top of the file: each application has the number of active, idle and idle-in-transaction connections, its role limit and a few connection lines (state|user|age in seconds|last query). MAX_CONNECTIONS is the server setting. The total bar, the shares (which add to exactly 100 by largest remainder), the header and the bar lengths are derived. On a real server these come from pg_stat_activity grouped by application_name.
Why do the bars share one scale?
So that applications can be compared: a short bar really is a small user of the pool. The tick on each row is that role's own limit on the same scale, so a bar approaching its tick is close to being refused. The note under the rows says so in words.
What do the three states mean?
Active is running a statement. Idle is connected and waiting for the next one. Idle in transaction has begun a transaction and is not doing anything, which holds locks and a snapshot open; it is hatched and named in the header when it is the story.
What is real here and what stays local?
The counts, pids and queries are typed examples and the product is made up; nothing connects to a server and nothing is closed. Choosing a row only changes what the list shows. In your app, closing a connection should be a server action behind its own confirmation.