Has anyone tried Boundary for PCI-scoped database access? Pitfalls?

I've been watching the chatter around using Boundary for PCI DSS scoped database access with a healthy dose of skepticism. Everyone seems enamored with the "zero trust" marketing lingo and the promise of replacing clunky VPNs, but I'm not convinced this is a silver bullet, especially for a regulated environment. The core idea of a dynamic, just-in-time access proxy is sound, but the devil is in the implementation details and the operational overhead that gets glossed over.

Let's talk about the actual pitfalls, not the theoretical ones. First, you're introducing a critical new component into your authentication and authorization chain. Boundary itself becomes a Tier 0 asset that needs to be protected, audited, and maintained. How are you handling its own high availability and disaster recovery? If Boundary goes down, your entire database access for PCI workloads vanishes. Have you fully modeled the failure scenarios and their impact on incident response or routine patching?

Second, the database credential brokering. The common pattern is to pair Boundary with Vault for dynamic secrets. Now you've got a two-system dependency. You need to deeply understand the trust relationship between Boundary workers, Vault clusters, and your database targets. Every network path, every mTLS certificate, every policy mapping is a potential misconfiguration waiting to happen. I've seen teams spend weeks untangling why a specific user session can't get a credential because of a subtle mismatch in Vault policy path names versus Boundary scope filters. The complexity isn't trivial.

Then there's the logging and audit trail. Boundary provides session recordings, but are they sufficient for your PCI auditor? You need to prove who connected, when, from where, and what they did. Boundary gives you the connection, but the actual SQL commands are still in your database logs. Correlating those two streams across systems is a new piece of work. You also need to ensure those session recordings are immutable and securely stored, which is yet another storage and compliance burden.

Finally, consider the total cost of ownership. It's not just the license cost. It's the time spent building the integration, the ongoing operational toil of managing worker deployments, scaling for performance, and keeping the entire stack patched. What happens when you need to upgrade Boundary and it has a breaking API change with your internal automation? You're building a significant piece of infrastructure that, depending on your deployment model, could lead to a form of vendor lock-in through deep workflow integration.

So, I'm genuinely curious for those who have gone to production with this: what did your security and compliance teams *actually* say during the audit? What was the one configuration headache that nearly made you abandon the project? How do you handle the scenario where an engineer legitimately needs a long-running session for debugging that outlasts a standard Vault dynamic secret TTL?

Just my two cents