# Watt Now Supports TanStack Start

## **TL;DR**

Watt 3.32 introduces first-class support for [TanStack Start](https://tanstack.com/start), the full-stack React framework from the creators of TanStack Query and TanStack Router. We benchmarked TanStack Start on AWS EKS under extreme load (10,000 req/s) and found that Watt matches single-process Node.js throughput and improves tail latency by 10%, consistently demonstrating measurable improvements.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769626611818/55d90d06-457e-4f4e-a7fa-0a15a840ef22.png align="center")

Both configurations were tested under identical conditions at a 10,000 req/s target load. The following section details the full methodology and raw data.

---

We’re excited to announce that Watt 3.32 adds native support for TanStack Start, bringing the same performance benefits that Next.js users have enjoyed to this rapidly growing full-stack React framework.

## **What is TanStack Start?**

TanStack Start is a modern full-stack React framework built on top of TanStack Router, Vinxi, and Nitro. It offers:

* **Type-safe routing** with first-class TypeScript support
    
* **Server functions** for seamless client-server communication
    
* **SSR and streaming** out of the box
    
* **File-based routing** with nested layouts
    
* **Built-in data loading** patterns from the TanStack Query team
    

For teams already using TanStack Query and TanStack Router, TanStack Start provides a natural progression to full-stack development with familiar patterns and excellent developer experience. Next, we'll explore why running TanStack Start with Watt is a strong architectural choice.

## **Why Watt for TanStack Start?**

Like Next.js, TanStack Start uses server-side rendering (SSR), which is CPU-bound and poses familiar scaling challenges:

1. Node.js runs on a single CPU core by default, underutilizing multi-core servers.
    
2. SSR frameworks require the full request context to gauge load, preventing early request rejection.
    
3. **Event loop blocking**: CPU-intensive rendering can cause the event loop to block, leading to latency spikes.
    

Watt addresses these with SO\_REUSEPORT, distributing connections at the kernel level across workers and removing IPC overhead. To validate this approach, our benchmark methodology is explained below.

## **Benchmark Methodology**

### **Infrastructure**

All benchmarks ran on AWS EKS (Elastic Kubernetes Service) with the following infrastructure:

* **EKS Cluster**: 4 nodes running m5.2xlarge instances (8 vCPUs, 32GB RAM each)
    
* **Region**: us-west-2
    
* **Load Testing Instance**: c7gn.2xlarge (8 vCPUs, 16GB RAM, network-optimized)
    
* **Load Testing Tool**: Grafana k6
    

The environment was ephemeral, created on demand via shell scripts and the AWS CLI, then torn down after each test run.

### **Software Versions**

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769626649425/81031ef5-0ceb-4bcd-b437-241a6bafc082.png align="center")

### **Resource Allocation**

Each configuration received identical total CPU resources:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769626664902/43028a05-994d-457e-95c9-f0bff4b500c9.png align="center")

Pods were distributed evenly across all 4 cluster nodes using topologySpreadConstraints.

### **Load Test Configuration**

We tested under extreme load to stress-test both configurations:

```javascript
export const options = {
 scenarios: {
   ramping_load: {
     executor: 'ramping-arrival-rate',
     startRate: 100,
     timeUnit: '1s',
     preAllocatedVUs: 1000,
     maxVUs: 10000,
     stages: [
       { duration: '20s', target: 2000 },   // Ramp to 2,000 req/s
       { duration: '20s', target: 5000 },   // Ramp to 5,000 req/s
       { duration: '20s', target: 8000 },   // Ramp to 8,000 req/s
       { duration: '20s', target: 10000 },  // Ramp to 10,000 req/s
       { duration: '100s', target: 10000 }, // Hold at 10,000 req/s
     ],
   },
 },
};
```

This configuration ramps up to 10,000 requests per second and holds for 100 seconds, deliberately exceeding the capacity of both configurations to observe behavior under stress.

### **Test Protocol**

1. **NLB Warm-up Phase**: All endpoints received a 60-second warm-up (ramping from 10 to 500 req/s) to ensure AWS Network Load Balancers were properly scaled
    
2. **Pre-test Warm-up**: Each runtime received a 20-second warm-up before its test
    
3. **Test Execution**: 180 seconds total (80s ramp + 100s hold at 10k req/s)
    
4. **Cooldown**: 480 seconds between each test to allow system recovery
    

## **Results**

### **Performance Summary**

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769626701516/5eed5c21-cfb9-40b3-b25d-c0a78c912e15.png align="center")

### **Latency (Successful Requests Only)**

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769626718132/e8e181d1-a4cc-48d8-be6d-94eed26e04c3.png align="center")

### **Key Observations**

1\. Equivalent Throughput Under Extreme Load

Both Watt and single-process Node.js achieved nearly identical throughput (~5,958 req/s) under the 10,000 req/s target load. This demonstrates that Watt’s multi-worker architecture introduces no overhead compared to running Node.js directly.

2\. Better Tail Latency with Watt

While average latencies were equivalent, Watt showed measurably better tail latency:

* **p99**: 263ms (Watt) vs 289ms (Node.js) - **9% improvement**
    
* **p95**: 221ms (Watt) vs 250ms (Node.js) - **12% improvement**
    
* **p90**: 196ms (Watt) vs 216ms (Node.js) - **9% improvement**
    

This improvement comes from SO\_REUSEPORT’s kernel-level load distribution, which prevents request pileup on any single worker.

3\. Slightly Higher Success Rate

Watt achieved a 79.3% success rate compared to Node.js’s 78.6% - a small but consistent improvement under stress. Both configurations were pushed well beyond their sustainable capacity (the target was 10k req/s, but actual throughput was ~6k req/s), so the high failure rates are expected.

4\. Test Was Deliberately Extreme

The 20%+ failure rate across both configurations indicates we successfully stress-tested beyond capacity. Under normal production loads (staying within throughput limits), both configurations would achieve near-100% success rates, as demonstrated in our Next.js benchmarks at 1,000 req/s.

## **Getting Started with TanStack Start on Watt**

Adding Watt support to your TanStack Start application requires minimal configuration:

### **1\. Install Dependencies**

`npm install wattpm @platformatic/tanstack`

### **2\. Create watt.json**

```json
{
 "$schema": "https://schemas.platformatic.dev/@platformatic/tanstack/3.32.0.json",
 "application": {
   "outputDirectory": ".output"
 },
 "runtime": {
   "logger": {
     "level": "info"
   },
   "server": {
     "hostname": "0.0.0.0",
     "port": 3000
   },
   "workers": {
     "static": 2
   }
 }
}
```

### **3\. Update package.json Scripts**

```javascript
{
 "scripts": {
   "build": "vite build",
   "build:watt": "NODE_ENV=production wattpm build",
   "start:watt": "wattpm start"
 }
}
```

### **4\. Build and Run**

`npm run build:watt`

`npm run start:watt`

That’s it. Watt will automatically detect your TanStack Start application and configure the appropriate build and runtime settings.

## **Kubernetes Deployment**

For Kubernetes deployments, the same principles from our Next.js guide apply. Here’s a sample deployment configuration:

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
 name: tanstack-watt
spec:
 replicas: 4
 template:
   spec:
     topologySpreadConstraints:
       - maxSkew: 1
         topologyKey: kubernetes.io/hostname
         whenUnsatisfiable: DoNotSchedule
         labelSelector:
           matchLabels:
             app: tanstack-watt
     containers:
       - name: tanstack-watt
         image: your-registry/tanstack-app:latest
         env:
           - name: WORKERS
             value: "2"
         resources:
           requests:
             cpu: '2000m'
             memory: '4Gi'
           limits:
             cpu: '2000m'
             memory: '4Gi'
         ports:
           - containerPort: 3000
```

Key points:

* Use topologySpreadConstraints to distribute pods evenly across nodes.
    
* Set WORKERS to match your CPU allocation (2 workers for 2 CPUs)
    
* Watt’s health monitoring will automatically restart unhealthy workers without terminating the pod.
    

## **Conclusion**

Watt 3.32 brings the same performance benefits to TanStack Start that Next.js users have enjoyed: kernel-level load distribution via SO\_REUSEPORT, zero-overhead multi-worker scaling, and external health monitoring to improve throughput and tail latency.

Our benchmarks show that under extreme load (10,000 req/s), Watt matches Node.js throughput while delivering measurably better tail latency (p99 improved by 9%, p95 by 12%). In production deployments constrained by capacity, both approaches achieve near-complete reliability.

If you’re building with TanStack Start and deploying to Kubernetes or any multi-core environment, Watt provides a straightforward path to better resource utilization and improved tail latency with minimal configuration changes.

The complete benchmark code is available at: [https://github.com/platformatic/k8s-watt-performance-demo.](https://github.com/platformatic/k8s-watt-performance-demo)

To get started with Watt, visit: [https://docs.platformatic.dev.](https://docs.platformatic.dev)

For questions or enterprise support, reach out to [info@platformatic.dev](mailto:info@platformatic.dev) or connect with us on [Discord](https://discord.gg/platformatic).