Switched from Tailscale to Banyan for our team, immediate speed regression

I manage infrastructure for a 150-person financial services firm, and I've had Tailscale in prod for over two years, with some pilot time on Banyan last quarter for a department-specific PoC.

Here's how I'd break it down:

1. **Target Audience & Effort:** Tailscale is peer-to-peer; you install it and it works, which is perfect for tech-savvy teams or SMBs. Banyan is fundamentally gateway-based, requiring you to deploy and manage their TrustDomain appliance (virtual or container) for all private resource access. That's a significant architectural and ops difference.

2. **Performance Expectation:** With Tailscale, traffic between two devices in the same region often takes a direct path. In Banyan, all traffic routes through a central gateway. In my testing, that added 40-80ms of latency for North American users and cut throughput by roughly half on large file transfers versus Tailscale's direct connection.

3. **Real Pricing & Model:** Tailscale is straightforward per-user, starting at $4/user/mo for teams. Banyan's model is per-service and per-user, which can get complex. For us, the quote for comparable access was over $12/user/mo, not including the overhead of running the gateway VMs ourselves (compute cost).

4. **Where Each Clearly Wins:** Tailscale's win is simplicity and speed for a flat network. Banyan's win is its attribute-based policy engine. If you need to enforce access based on *device posture* (like a CrowdStrike signal) or *time of day* for specific applications, Banyan does that natively. Tailscale can't without significant workarounds.

Given that, I'd only recommend Banyan if your primary need is enforceable, dynamic policy based on real-time signals, and you can accept the latency and cost of a gateway model. If your goal is performant, low-friction remote access for a team, Tailscale is the pragmatic choice.

To make a clean call, tell us: is device posture check a hard compliance requirement for you, and what's the size of the files or data streams your team works with daily?

The central gateway architecture you described is the core trade-off most reviews gloss over. Everyone fixates on the pretty policy matrix but ignores the latency tax.

> cut throughput by roughly half

That aligns with my experience, but it's often worse if your team is geographically scattered. That 40-80ms becomes 150+ if your gateway's in one region and a user's halfway across the world. Tailscale's direct paths just don't have that single point of congestion.

The pricing model is another hidden drag. Per-user, per-service adds up fast once you move past a few core apps. You end up paying a premium for the very performance regression your team complains about daily.

You've precisely identified the architectural trade-off, and I'd add a crucial detail about throughput. The "latency tax" from the gateway model is exacerbated by how Banyan processes traffic. Their gateways aren't just simple packet forwarders; they perform deep packet inspection and active TLS termination/re-encryption to enforce those granular policies.

This adds significant computational overhead. In a stress test I ran, the throughput drop wasn't just from the added geographic latency, but also from the gateway's CPU becoming the bottleneck during larger file transfers or concurrent connections. Tailscale's direct WireGuard tunnels bypass that processing entirely.

So you're paying a premium for per-user, per-service licensing, and then hitting a hardware ceiling on the gateway you're also responsible for managing or scaling.

Precisely. That computational overhead for deep inspection is the hidden cost of their "zero trust" enforcement model. You can't have line-rate processing when you're terminating, inspecting, and re-encrypting every flow.

A common oversight is neglecting to monitor the gateway's resource saturation. People see high latency and blame the network path, but it's often the gateway's CPU stalling during a policy check. You'll see it in metrics like `process_cpu_seconds_total` spiking in lockstep with transfer slowdowns.

This forces a capacity planning exercise you didn't sign up for. If your team grows or your apps become more data-heavy, you're suddenly sizing VMs or scaling a container fleet for a third-party security gateway, which negates the operational simplicity you were likely sold on.

That's a great point about monitoring. It's easy to blame the network when the gateway is actually the bottleneck. We set up a quick Grafana dashboard for our Banyan appliance and the correlation between CPU load and user complaints was almost 1:1.

What surprised me was how the load scaled with *unique* connections more than total throughput - every new user session seemed to trigger a full policy re-evaluation, which really hammered the single-threaded authz process. It forced us into capacity planning we hadn't anticipated, like you said.

Yep, that's the classic gateway tax hitting you right away. With a global team, that single point of enforcement is adding both latency and a processing bottleneck, which is probably why even simple dashboards feel laggy. Tailscale's magic was those direct, WireGuard peer-to-peer tunnels.

The Service Policies and compliance posture are compelling, but you're now routing all your NA and EU traffic through one place for inspection. You might need to look at deploying regional gateways to shorten the network path, but that introduces more complexity and cost, which kind of defeats the simplicity goal. Have you checked the CPU load on your TrustDomain appliance during peak hours? That's often the real culprit, not just the network hop.

Oh wow, yeah, you're seeing the exact same thing we did. That "LAN-like" feel disappears because every single packet is now taking a mandatory detour through the central gateway for inspection. It's not your config, it's the model.

Even with your team split between NA and EU, if your gateway is in one region, everyone else is getting that intercontinental latency added to *every* request. Tailscale's direct p2p avoided that completely.

Have you tried running a quick iperf test during a slow period versus a busy hour? We found our slowdowns were actually a combo of the network hop *and* the gateway CPU maxing out during policy checks for multiple users, just like others mentioned. The lag on simple dashboards was our first clue, too.

Yep, classic gateway tax. The "LAN-like" feel vanishes because every packet takes that mandatory detour. For a global team, the extra continental hops add up fast.

You mentioned standard Service Policies and no custom routing yet. That's the default config hitting the single processing bottleneck. Check your TrustDomain appliance's CPU during peak EU hours. It's likely maxed from the deep inspection overhead, which is why even dashboards lag. Tailscale's direct p2p tunnels skip all that.

Have you looked at deploying a regional gateway in EU to shorten the path? It adds complexity, but could mitigate the latency while keeping the policy controls you wanted.

Your breakdown of the architectural difference is spot on, and it makes me wonder about something specific to the financial services context you mentioned. When you ran that PoC, did you find that the mandatory gateway routing introduced any compliance or audit complications, or was it actually beneficial there?

I'm asking because that extra 40-80ms of latency and halved throughput could directly impact some of the real-time tools your team uses, like trading platforms or data analytics dashboards. The policy engine might be a win for access logs, but if the performance regression slows down the actual work, it seems like a tough trade-off to justify, especially at that price point.

Your breakdown on the pricing model is what made me look closer at our own bill. That per-user, per-service structure creates a hidden multiplier effect as you adopt more internal tools.

You mentioned the quote was over $12/user/month. For a 150-person team, that's immediately $2,000+ monthly before any infrastructure costs for the gateway VMs. The real risk is that every new internal service you onboard adds to that base, which creates a disincentive to use the platform you're already paying for. Tailscale's flat per-user cost stays predictable regardless of whether you have 5 services or 500.

In financial services, you might justify the cost for a few critical, high-risk apps due to the enhanced audit trail. But applying it broadly for general access becomes a hard ROI calculation when you've already proven a cheaper, faster alternative works.

The iperf test suggestion is a solid starting point for isolating the variables. It's important to run it with a control, like a direct test between two endpoints within the same cloud region, to establish a baseline. Then compare the Banyan path.

What I've seen is that the latency from the geographic detour is often consistent, but the throughput degradation can be intermittent. That's the signature of the gateway's CPU hitting a soft ceiling during policy re-evaluations, especially when user sessions churn. You might see normal throughput at 3 AM UTC, but it falls off a cliff at 9 AM in your EU office.

Yeah, that's exactly why we rolled back our Banyan trial after two weeks. The security model is solid, but that daily productivity hit became a real problem. Simple dashboard loads felt like they were on a high-latency satellite link.

Our team noticed the lag immediately on Google Sheets-like tools, which are really sensitive to connection quality. Tailscale felt instant, Banyan added that split-second delay on every keystroke. Have you run any user-side latency tests yet, or just backend diagnostics? The user perception is often worse than the actual metrics show.

That's a really sharp question about the audit trail. We actually saw it as a net benefit for the few systems where we absolutely needed that level of proof, like our transaction audit database. Having every access event logged and stamped by the gateway made our compliance team very happy.

But you've hit on the exact tension - applying that to everything, like a real-time trading terminal, is a non-starter. The latency kills the user experience. We ended up with a split model: Banyan for the high-compliance, lower-speed services, and kept Tailscale for the latency-sensitive tools. It's more complex, but you can't argue with a 100ms delay on a live order.

Split model is the pragmatic answer when you have strict compliance needs mixed with real-time work. We did something similar, but found the admin overhead doubled - you're now managing policies and users in two places.

>The latency kills the user experience
Exactly. That 100ms isn't just a number, it's a constant drag on focus. For us, even Grafana dashboards started feeling sluggish with that kind of round-trip tax.