Has anyone successfully used Boundary for database *query* logging?

I've been evaluating Boundary for the last six months in a hybrid environment where we have strict compliance requirements to log all database access, not just the *session* but the actual *queries* executed. The marketing and initial docs suggest Boundary is about secure session management, but the details on true query-level audit trails are... let's say, buried under layers of "just use the session recording" hand-waving.

Our use case: legacy reporting tools and custom scripts that need PostgreSQL and MySQL access. We can't just give them the keys to the kingdom; we need to know *what* they asked for, not just that they connected. Boundary's built-in session recording is fantastic for SSH or RDP, but for databases, it's a TCP proxy. It sees the encrypted tunnel, not the SQL inside.

After much trial, error, and middleware horror, here's the semi-successful, Frankensteinian architecture we landed on:

* **Boundary** handles the brokering, authentication, and authorization. It establishes the session to the target database (via the `postgres` or `mysql` target types).
* **A custom sidecar proxy** is the real workhorse. We deploy it as a container alongside Boundary workers. It listens locally, and the Boundary target points to this local proxy instead of directly to the database.
* **This proxy** does TLS termination (if needed), logs the raw SQL queries (parsing the wire protocol for PostgreSQL/MySQL), and then forwards the traffic to the actual database. The logs are shipped to our SIEM.

A simplified, anonymized config snippet for the Boundary target:

```hcl
resource "boundary_target" "postgres_audited" {
name = "prod-db-audited"
type = "tcp"
scope_id = boundary_scope.project.id
default_port= 5432
# This host_source_id points to a worker-filtered set
host_source_ids = [boundary_host_set_static.monitored_workers.id]
# Critical part: the address is localhost, where our sidecar runs
address = "localhost:15432"
}
```

The pitfalls are, as you'd expect, monumental:

* **Performance overhead:** Parsing the wire protocol isn't cheap. We see 5-15ms added latency per query, which our reporting team *loves* to complain about.
* **Stateful complexity:** The proxy must manage connection state, prepared statements, and cursors correctly. One bug and you're leaking connections or returning malformed data.
* **It's entirely custom.** HashiCorp provides zero support for this pattern. You're on your own for maintenance, scaling, and protocol updates.
* **Session recording becomes useless** for the actual query content. It just shows bytes flowing through a TCP stream to `localhost:15432`. The audit trail is now split across two systems (Boundary for who/when, our proxy for the what).

So, to answer the implicit question: yes, but not with Boundary alone. You're essentially using it as a fancy gatekeeper while building your own logging infrastructure behind its walls. I'm curious if anyone else has gone down this rabbit hole and found a less brittle approach, or if you've convinced your compliance team that session-level logging is "good enough" (a battle I lost).