Live data from Hacker News

PgX – Debug Postgres performance in the context of your application code

docs.base14.io

11–12 of 12 posts

Re: PgX – Debug Postgres performance in the context of your application code

#11

> The engineer is forced into manual correlation: jumping between dashboards, aligning timelines by eye, [and] inferring causality from coincidence I just generate a random UUID in the application and make sure to log it everywhere across the entire stack along with a timestamp. Any old log aggregator can give me an accurate timeline grouped by request UUID across every backend component all in one dashboard. It's th…

founder at base14 here, the company that is building Scout. Thanks for the feedback. we do something similar for tracing as well, but pgX does a bit more than that - engineers should be able to trace (like you mention) and see and analyse the condition of the DB. for eg - correlate query slowdown to locks, vacuums etc. all on one screen, or a couple of clicks. We are building some specialised explorers like pgX for postgres. Essentially we are building telemetry readers for components that send relevant metrics and logs through to a telemetry data lake. for each component/domain we find from experts what they look at for analysis and incidents, and bring that to a full stack "unified" dashboards/mcp.

Scout is our otel-native observability product (data lake, UI, alerts, analytics, mcp, the works). what we call pgX in the blog is an add-on to Scout.

Post reply on HN