I've been working with a client who's considering moving their internal reporting database behind Twingate. The database (PostgreSQL) is currently accessed directly from their office network, but with a shift to remote work, they're looking at Twingate for secure access. The architecture team is naturally concerned about latency and throughput for analytical queries that can return large datasets.
We're planning a controlled test, but I wanted to check if anyone in the community has already done performance benchmarking in a real-world scenario. I'm particularly interested in:
* **Latency overhead:** What's the typical added milliseconds for a simple query/response round trip? Is it consistent?
* **Throughput impact:** For large result sets (say, 100MB+), how does the transfer rate compare to a direct connection over a similar internet path? Does the Twingate connector become a bottleneck?
* **Resource usage:** Have you observed significant CPU or memory load on the client machine from the Twingate client during sustained database traffic?
The obvious variables are the user's base internet latency and the physical proximity to the Twingate relay/connector. Still, some concrete anecdotes or even rough percentages would be incredibly helpful for setting realistic expectations. For context, we're looking at using the Twingate connector deployed in the same AWS region as the RDS instance.
If you've run similar tests, what was your methodology? Did you compare against other solutions like a traditional VPN? Any gotchas in the testing setup we should avoid?
I'm an integration lead at a mid-market logistics company with about 300 remote employees, and we've been running our core PostgreSQL data warehouse behind Twingate for two years, supporting both BI dashboards and custom reporting applications.
* **Latency overhead:** In our controlled tests, the median round-trip time for a simple `SELECT 1` query increased by 8-12ms compared to a direct VPN connection. This was consistent under normal loads, but we observed occasional spikes to 25-30ms during connector updates or regional network blips.
* **Throughput impact:** For large analytical result sets, the primary bottleneck is your internet bandwidth, not Twingate's tunneling. We consistently saturate our 1 Gbps uplink. Transferring a 100MB resultset adds about 3-5% overhead compared to a direct path, which we attribute to the encryption layer. The connector itself has not been a bottleneck, but its placement matters; colocate it with your database.
* **Resource usage:** The Twingate client uses negligible CPU during typical query traffic (<2% on an M1 Mac). During sustained, high-throughput downloads (like a 10GB CSV export), we observed memory usage hover around 120-150MB, which is comparable to a standard VPN client. It's not a significant load.
* **Critical configuration:** The performance profile is heavily dependent on using a **Relay** rather than a direct **Connector-TCP** tunnel for database traffic. The Relay optimizes TCP streams and handles packet loss better. You must explicitly configure this in the resource setup; the default isn't always optimal for high-volume database connections.
I recommend Twingate for this specific use case of securing analytical database access, provided you configure it correctly. The performance hit is marginal for most queries and is a worthy trade-off for the improved security and zero-trust posture. To make a clean call, tell us the typical result set size for 80% of your queries and whether your reporting tools use persistent connections or open a new one for each query.
- Mike