3 ms·

Why do you need a proxy? Pull the queries off the network. You’re adding latency to every query! https://github.com/circonus-labs/wirelatency https://github.co

• nimrody 8mo ago
  Won't work for SSL encrypted connections (but, yes, this does add some latency)
  • ranger_danger 8mo ago
    eBPF will: https://eunomia.dev/tutorials/40-mysql/ https://eunomia.dev/tutorials/40-mysql/
    • tudorg 8mo ago
      Even then, though, it needs to run on the server so it's hard to guarantee to not impact performance and availability. There are many Postgres/Mysql proxies used for connection pooling and such, so at least we understand their impact pretty well (and it tends to be minimal).
• deleted 8mo ago
  [deleted]
• andreadev 8mo ago
  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.
  • PunchyHamster 8mo ago
    You can decode TLS traffic with a little bit of effort, tho you have to control the endpoints which makes it a bit moot as if you control them you can just... enable query logging
    • andreadev 8mo ago
      True, but logging tells you what happened, a proxy lets you decide what's allowed to happen before it hits the database. Policy enforcement, tenant isolation, that kind of thing. They're complementary really.
  • debarshri 8mo ago
    Also, just to add to this, to run compile once and run anywhere, you need to have a BTF-enabled kernel.
    • andreadev 8mo ago
      Exactly, and that's one more reason I went with a userspace proxy — no kernel deps, runs anywhere, way easier to debug.
  • singpolyma3 8mo ago
    TLS for your database? Are you connecting outside of the local machine or VPN?
    • andreadev 8mo ago
      Yeah, more and more. Zero-trust is pushing TLS everywhere, even inside VPNs — lateral movement is a real thing. And several compliance frameworks now expect encryption in transit regardless of network topology. With connection pooling the overhead is basically zero anyway.
      • freedomben 8mo ago
        Indeed, if you're running the db in production and aren't using TLS, you're doing it wrong nowadays. Nearly every compliance framework will require it, and it's a very good idea anyway even if you don't care about compliance.