Tailscale's New Performance Push: Multi-Queue, Netmap Caching, and Lower Overhead

Tailscale’s Need for Speed

Tailscale has long been praised for its ability to punch through NATs and connect devices across hostile networks. But the company knows that connectivity is only half the battle. The data plane—the actual packet forwarding—must also be fast enough for modern workloads like CI/CD, remote development, and edge AI. That’s why the team has been on a multi-year quest to squeeze every bit of performance out of its WireGuard-based mesh.

The latest round of improvements, detailed in a September 2026 blog post, targets several bottlenecks: memory overhead for small packets, single-threaded processing on high-traffic nodes, and slow startup when the control plane is unreachable. These changes promise a tangible boost for users running subnet routers, app connectors, and exit nodes, as well as anyone connecting from flaky networks.

The 64 KiB Buffer Problem

Most network packets are tiny—around 1 KiB. But Tailscale’s WireGuard implementation, wireguard-go, allocates a single 64 KiB buffer for every incoming packet. That means a 1 KiB packet gets copied into a 64 KiB buffer, wasting memory and CPU cycles. It’s like shipping a single box in a 40-foot container.

On Linux and Android, Tailscale now avoids this copy by leaving packets where they land and tracking their boundaries within the larger read buffer. This simple change yields a ~5% speed-up in many configurations. Additionally, the team shortened packet queues, which were found to be deeper than necessary, reducing latency and memory overhead further.

Multi-Queue: Spreading the Load

Subnet routers, app connectors, and exit nodes often handle hundreds of concurrent streams. Until now, they processed packets in a single ordered pipeline, meaning all streams shared one lane. That’s inefficient on modern multi-core hardware.

Tailscale’s new multi-queue system creates multiple parallel lanes, each handling a distinct stream of packets. This spreads work across CPU cores, increasing aggregate capacity and reducing latency. “This translates into lower latency, essentially faster processing of data from the moment we read it off the wire to the moment we send it to the OS,” said Alex Valiushko, member of technical staff at Tailscale. The benefit is most pronounced for app connectors and exit nodes, which serve many short-lived connections.

writev: Fewer Copies, Higher Throughput

Another Linux-specific optimization leverages the writev system call. Instead of combining multiple packet pieces into a single buffer before sending them to the kernel, Tailscale can now pass a vector of data segments in one operation. This eliminates copies and reduces system calls, boosting throughput. The change is partially implemented in the spring 2026 client, with further gains expected after v1.104.

Netmap Caching: Instant Startup on Bad Networks

When a device boots, it normally contacts Tailscale’s control plane to fetch a network map (netmap) of its peers. On a good connection, this takes ~100ms. But on airplane Wi-Fi or hotel networks, it can take seconds or fail entirely.

Netmap caching solves this by storing a copy of the netmap on disk. On startup, the device can use this cached map to establish direct peer connections immediately, even before reaching the control plane. Claus Lensbøl, member of technical staff, notes: “Bad network conditions—that’s really the space where people can get a lot of utility out of netmap caching.” In tests, warm-cache starts were one to two orders of magnitude faster than cold starts.

The feature requires the device to have connected at least once and have persistent storage. It’s currently behind a feature flag, but will be enabled by default in v1.104. Mobile clients will get it later.

Rollout Timeline and Availability

• Memory reduction (Linux/Android): v1.104
• Multi-queue for subnet routers/app connectors: after v1.104
• writev throughput: partially in spring 2026, more after v1.104
• Netmap caching: feature flag now, default in v1.104; mobile later

The Kernel WireGuard Debate

Some users ask why Tailscale doesn’t just use kernel WireGuard. Founder Avery Pennarun addressed this on Hacker News: “Our optimizations made wireguard-go faster than kernel wireguard because it was better optimized. They adopted some of those improvements and now we’re on to the next order of magnitude together.” He also noted that WireGuard’s crypto isn’t hardware-accelerated, and for ultra-high bandwidth, userspace DPDK is the long-term answer.

Performance Tooling Gaps

Tailscale acknowledges that diagnosing network performance is still hard. Existing tools lack Tailscale-awareness—they can’t tell if a connection is direct or via DERP, or how paths change over time. The company is exploring a Tailscale-native monitoring toolkit and has opened a Typeform for community input.

Why It Matters

These improvements make Tailscale more viable for performance-sensitive workloads like CI/CD pipelines, telemetry, and edge robotics. The multi-queue and memory optimizations mean existing hardware can handle more traffic, while netmap caching ensures devices connect faster even under adverse conditions. As Tailscale continues to push performance, it solidifies its position as a serious alternative to traditional VPNs and even kernel WireGuard.