Feature Preview: Diagnose blocked queries with Database Connections

[joshenlim]

We're excited to introduce Database Connections as a feature preview 🎉

When your app is slow or hanging, the cause is usually happening at the database level — a query that's stuck, one session blocking a dozen others, or a connection pool running dry. Postgres actually surfaces all of this through pg_stat_activity, but figuring out which query, which session, or what's holding the lock usually means knowing which system view to query and how to read it — not something you want to learn mid-incident.

Database Connections gives you a live view of what's happening on your database right now, without writing SQL:

• See every active session, its query, and how long it's been running
• Get flagged the moment something's idle in transaction, blocked, or running longer than expected
• Trace a blocked query back to the session actually holding the lock — even through multiple hops
• Terminate the stuck session directly from the table
• Ask the AI Assistant to summarize current activity in plain English

What we'd like to know from you

• Any bugs or issues that you might have run into while using the Database Connections page
• Any ideas or suggestions that you reckon will improve the DX based on how you debug or diagnose stucked queries on your database
• Feel free to leave any feedback in this thread too! (Both good and bad!) 🙂🙏

[pacocartones]

This looks especially useful during incidents. One design detail that could make it safer to use under pressure is to separate the diagnostic evidence from the query text itself.

pg_stat_activity can contain application data in statement literals, and the usefulness of a session view also depends on the role that is allowed to inspect it. It would help if the UI made the following explicit:

• whether displayed statements are redacted or truncated, and by which rule;
• which role/permission boundary produced the view;
• an exportable lock-wait chain with stable session identifiers and timestamps; and
• a strong confirmation step for termination that re-checks the target session immediately before acting.

The same boundary matters for an AI summary: users should be able to tell what data is sent to it and what has been redacted. I have not used the preview yet, so this is a design question rather than a report of current behaviour, but these guardrails would make the feature much easier to trust in production.

[joshenlim]

this is great feedback thank you so much! 🙏 🙂 appreciate it! we'll have a look at how we can tweak the UI based on this! 🙏