Back to Signal
rust performance systems

When to Use Rust (And When Not To)

Rust is a hammer. Not every problem is a nail. Here's how we decide when to reach for systems programming.

February 12, 2026 • — min read

Core Concept

Rust has a marketing problem. The community makes it sound like you need Rust for everything, or you’re not a “real” engineer.

The truth: Rust is for when Node.js or Python are measurably too slow. If you can’t measure the bottleneck, you don’t need Rust.

The Constraint

Rust’s development velocity is 3x slower than Node.js.

Why?

  • The borrow checker fights you on every data structure
  • Async programming requires tokio (steep learning curve)
  • Hiring is hard (10x fewer Rust engineers than JS engineers)
  • Debugging is painful (no REPL, long compile times)

Use case breakdown:

ScenarioUse Rust?Why
CRUD API❌ NoNode.js + Express is fine. Use Fastify if you need speed.
Real-time WebSocket server✅ YesHandling 100K concurrent connections requires Rust/Go.
Payment processing sidecar✅ YesSub-millisecond latency required (no GC pauses).
Image resizing worker✅ YesCPU-bound task, parallel processing matters.
Cron job / scheduler❌ NoNode.js cron is perfectly fine for this.
Machine learning inference✅ MaybeRust bindings to ONNX are faster than Python, but use Python until you have scale.

The Solution

We use Rust for exactly 3 things:

1. Payment Processing Sidecars

When we process credit card transactions, we can’t afford Node.js’s 10ms GC pauses. Stripe webhooks must respond in under 50ms, or they retry (causing duplicate charges).

Stack: Rust + Actix-web + Redis

Result: 2ms p99 latency (vs 45ms with Node.js)

2. Real-Time Infrastructure

For Politorium (political data platform), we have 50K concurrent WebSocket connections streaming live election results.

Node.js problem: Each connection consumes 10MB of memory (V8 overhead).
Rust solution: Tokio handles each connection in 2KB (500x efficiency).

Stack: Rust + tokio + tungstenite

Result: $800/month server cost (vs $8K for Node.js cluster)

3. Data Pipeline Workers

When processing 10TB of video for LyveCom, ffmpeg + Node.js couldn’t saturate our CPU cores. The GC kept pausing mid-encode.

Stack: Rust + rayon (parallel processing) + ffmpeg bindings

Result: 16-core utilization, 4x faster video processing

The Trade-Off

When NOT to use Rust:

❌ Your API layer: Use Node.js/Bun. It’s 10x faster to iterate.
❌ Your frontend: Use Flutter or React. Rust + WebAssembly is overhyped.
❌ Your database layer: Use Postgres. Don’t write your own storage engine.
❌ Your MVP: Use whatever you know best. Premature optimization kills startups.

When TO use Rust:

✅ After profiling shows Node.js is the bottleneck
✅ When latency SLAs are in your contract (fintech, gaming)
✅ When cost matters (100K concurrent users, not 100)

The Decision Tree

Is your Node.js service measurably too slow?
  ├─ No → Keep using Node.js
  └─ Yes → Can you fix it with better algorithms?
      ├─ Yes → Optimize Node.js (add Redis, fix N+1 queries)
      └─ No → Is this performance-critical to your business?
          ├─ No → Live with it (ship features instead)
          └─ Yes → Rewrite this one microservice in Rust

The First Principle: Use boring technology until the problem demands otherwise. Rust is not boring yet.

Back to Signal