I get what you're saying about a proxy like this, latency & performance would suffer, however minor, and in production DB land this really matters.

I've just not sure it is much of a slight on such proxies.

You don't need to run this always inline in production to get amazingly useful results. Yes, there are lots of production insight solutions out there, but lots of modern stacks can be complex enough that just getting a quick handle on how the page you're debugging talks to your DBs can be incredibly useful, which is where I love the idea of a solution like this.

Sure, it is mytop / pgtop, but trying to offering it at a different layer & with a modern interface. Seems useful to me.

> The Postgres extension model to capture the metrics (we also experimented with eBPF, but it causes too many kernel-user space context switches when you can do the same in an extension without them), and a small sidecar to push the metrics out via a standardized protocol like OTEL.

The extension model is great, but it doesn't work with existing postgres providers (RDS, Aurora, etc.). Unless one such extension becomes standard enough that all providers will support it. That would be ideal, IMO.

To be clear, I don't mean pg_stat_statements, that is standard enough, but an extension that pushes the actual queries in real-time.

> If it's a network hop, then adds milliseconds, and not microseconds.

Are you talking about connection establishing time or for query delay? I think it should normally be under a millisecond for the later.

I was with you until you said react. Just export to existing metrics software like Prometheus. Or do anything other than use an entire JavaScript framework for a simple UI. I swear, JS-Brain is as terminal as microservice and cloud brain.

The proxy vs packet capture debate is a bit of a non-debate in practice — the moment TLS is on (and it should always be on), packet capture sees nothing useful. eBPF is interesting for observability but it works at the network/syscall level — doing actual SQL-level inspection or blocking through eBPF would mean reassembling TCP streams and parsing the Postgres wire protocol in kernel space, which is not really practical.

I've been building a Postgres wire protocol proxy in Go and the latency concern is the thing people always bring up first, but it's the wrong thing to worry about. A proxy adds microseconds, your queries take milliseconds. Nobody will ever notice. The actual hard part — the thing that will eat weeks of your life — is implementing the wire protocol correctly. Everyone starts with simple query messages and thinks they're 80% done. Then you hit the extended query protocol (Parse/Bind/Execute), prepared statements, COPY, notifications, and you realize the simple path was maybe 20% of what Postgres actually does. Once you get through that though, monitoring becomes almost a side effect. You're already parsing every query, so you can filter them, enforce policies, do tenant-level isolation, rotate credentials — things that are fundamentally impossible with any passive approach.

Won't work for SSL encrypted connections (but, yes, this does add some latency)

Lol yeah.. Anyway in any serious application queries fly past like crazy, create temporary tables, pull the columns from several, and do stuff that's hard to interpret on the fly. Especially a software you just use, didn't write.

Turning on logging is likely more useful. Have done that to understand inner workings of some financial apps.

Or log_statement = 'all' in Postgres.

You don't need to access (or even have access to) the DB server itself (e.g. to read the query-log), you can do everything by just setting a different host to connect to.

yes, this was my first question.

why would i inspect this data, because maybe trying to find a cause to a problem.. are there any other reasons

I prefer to just turn on query logging in the db server. I don't understand why you would use anything else.