Show HN: SQL-tap – Real-time SQL traffic viewer for PostgreSQL and MySQL (github.com)
sql-tap is a transparent proxy that captures SQL queries by parsing the PostgreSQL/MySQL wire protocol and displays them in a terminal UI. You can run EXPLAIN on any captured query. No application code changes needed — just change the port.
24 comments
[ 3.1 ms ] story [ 37.0 ms ] threadI just tried and it works smoothly. For those who doesn't want to plug in the agents to their database directly, I built a similar tool https://dbfor.dev for the exact purpose, it just embeds PGLite and implements PG wire protocol to spin up quick PG databases with a traffic viewer included.
What you can also do is add frontend and backend user to the proxy and then agents won't ever get the actual db user and password. You can make it throwaway too as well as just in time if you want.
Traditionally it was database activity monitoring which kind of fell out of fashion, but i think it is going to be back with advent of agents.
[1] https://adaptive.live
[0]: https://pgtap.org/
If so, would you mind sharing which model(s) you used and what tooling?
https://github.com/circonus-labs/wirelatency
What I would love to see here is:
- some kind of sorting: eg. by excecution time or order. So I can see the slowest queries.
- search/filter feature.
- faster scrolling with pgup/pgdown keys.
- maybe how often the same query was executed. I could check the code and maybe optimize the queries.
https://eunomia.dev/tutorials/40-mysql/
There's two main problems with said proxies:
* Latency. Yes, yes, yes, they add "microseconds" vs "milliseconds for queries", and that's true, but just part of the story. There's an extra hop. There's two extra sets of TCP layers being traversed. If the hop is local (say a sidecar, as we do in StackGres) it adds complexity in its deployment and management (something we solved by automation, but was an extra problem to solve) and consumes resources. If it's a network hop, then adds milliseconds, and not microseconds.
* Performance. It's not that hard to write a functioning PG wire proxy (it's not trivial either). But it is extremely hard to make it perform well under high load scenarios. Most of the proxies I have seen crack down under moderate to high performance.
What's the solution then? 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.
[1]: https://www.envoyproxy.io/docs/envoy/latest/configuration/li...
[2]: https://www.cncf.io/blog/2020/08/13/envoy-1-15-introduces-a-...
[3]: https://stackgres.io
Edit: formatting
https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overv...