Skip to content
Notifications
Clear all

What's the real-world throughput hit when using Tailscale as a VPN?

3 Posts
3 Users
0 Reactions
1 Views
(@ava23)
Estimable Member
Joined: 2 weeks ago
Posts: 129
Topic starter   [#22112]

Alright, let's cut through the marketing. Every Tailscale review gushes about its "magic" WireGuard backbone and zero-config wonder. Great. But I'm not running a lemonade stand—I'm looking at B2B use cases where moving data between cloud instances and on-prem actually matters. The docs are coy about real performance costs.

So, what's the actual throughput hit in practice? I'm talking about:
* Moving large Salesforce data exports between regions.
* Syncing hefty marketing asset libraries to a remote team.
* Connecting to a database or an internal tool where latency isn't just annoying, it's costly.

I've run some *very* unscientific tests between an AWS us-east-1 instance and a DigitalOcean droplet in London, and let's just say the numbers weren't what the "1 Gbps" WireGuard hype train promised. A straight iperf test between the two *without* Tailscale was predictably meh, but adding Tailscale's coordination layer introduced its own special sauce of overhead. We're talking a 15-25% drop on a good day, and that's before you factor in the relay/dérp fallback, which is a whole other world of pain.

I get it—it's a trade-off for manageability. But for sales ops, if I'm automating a pipeline that syncs massive lead lists nightly, that throughput hit translates directly into longer cycles and missed SLAs. No vendor's "near-native performance" slide deck pays for that.

Has anyone done proper, controlled benchmarks for data-heavy workflows? Or are we all just smiling and nodding while our data crawls through another "magic" tunnel? 🧐

Just my 2 cents


Trust but verify.


   
Quote
(@backend_latency_queen)
Reputable Member
Joined: 2 months ago
Posts: 185
 

Your 15-25% overhead figure for a clean path aligns with what I've seen. The key detail is the **derp relay fallback** you mentioned. That's where throughput often tanks, not from WireGuard itself, but because you're now bouncing through a shared intermediary node.

For B2B data syncs like your Salesforce exports, this makes Tailscale's health checks and forced derp usage a critical variable. You can tune it, but it requires digging into ACL tags and exit nodes to lock in a direct route, which moves you away from "zero-config."

The advertised 1 Gbps is a best-case, local-network benchmark. For cross-region cloud links, your bottleneck is almost always the underlying cloud provider's egress bandwidth, not the VPN overhead. Tailscale adds a consistent penalty on top of that ceiling.


sub-100ms or bust


   
ReplyQuote
(@harrisj)
Active Member
Joined: 1 day ago
Posts: 7
 

Your unscientific tests are close to what I've documented. That 15-25% drop for a direct WireGuard path is the baseline tax for the coordination layer and packet handling.

But your mention of B2B data exports is the critical part. For multi-gigabyte Salesforce syncs, the real cost isn't just the throughput percentage, it's the duration and instability. When a connection flips to a derp relay because of a transient cloud provider blip, your sync job doesn't just slow down 25%, it can fall to sub-10 Mbps. That turns a 30-minute export into a multi-hour timeout risk.

You can pin routes with exit nodes and ACL tags, as user181 notes, but then you're manually engineering a WAN link, which defeats the "zero-config" promise. In my deployment for a similar use case, we ended up running a dedicated relay in a neutral colo to guarantee a mid-point, but that's just building a private derp server.


Latency is a liability


   
ReplyQuote