Rust in Production: How Grab Cut Cloud Costs 70% and Why Backends Are Rewriting

The Enterprise Chasm Is Crossed

Rust crossed the enterprise adoption chasm in 2026. 45% of enterprises now run Rust workloads in production, up 40% in just twelve months. JetBrains' State of Rust Ecosystem report (February 2026) confirms what engineering teams have been experiencing: Rust is no longer experimental. It's a production language for performance-critical backends.

The catalyst wasn't Rust's safety guarantees or its type system — engineers already knew those were excellent. The catalyst was money. Specifically, Grab's published case study showing their Go-to-Rust migration cut infrastructure costs by 70%, reducing CPU requirements from 20 cores to 4.5 for the same 1,000 requests per second.

When a company the size of Grab publishes those numbers, engineering managers pay attention.

Grab's Migration: The Numbers

Grab is Southeast Asia's largest ride-hailing and delivery platform, serving millions of users across 8 countries. Their backend handles billions of requests daily.

Before (Go)

Service: Payment processing middleware
Language: Go 1.21
CPU: 20 cores allocated
Memory: 2.4 GB per instance
Throughput: 1,000 req/sec
P99 latency: 45ms
Instances: 12
Monthly cost: ~$3,600 (compute only)

After (Rust)

Service: Payment processing middleware (rewritten)
Language: Rust 1.76 (Tokio + Axum)
CPU: 4.5 cores allocated
Memory: 180 MB per instance
Throughput: 1,000 req/sec
P99 latency: 12ms
Instances: 4
Monthly cost: ~$900 (compute only)

The Breakdown

• CPU reduction: 77.5% (20 cores → 4.5 cores)
• Memory reduction: 92.5% (2.4 GB → 180 MB per instance)
• Latency improvement: 73% (45ms P99 → 12ms P99)
• Instance reduction: 67% (12 → 4 instances)
• Cost reduction: 75% ($3,600 → $900/month)

The memory reduction is the headline. Go's garbage collector, while excellent, introduces overhead. Each Go instance carried hundreds of megabytes of GC overhead. Rust has no garbage collector — memory is managed at compile time through the ownership system. The result: memory footprints dropped from hundreds of MB to under 100 MB.

Why Go Teams Are Looking at Rust

This is not a "Go is bad" story. Go remains an excellent language for many use cases — CLIs, simple web services, DevOps tooling, rapid prototyping. But for specific workload patterns, Rust offers measurable advantages:

Pattern 1: High-Throughput Data Processing

// Rust: Process 1M records with zero allocations in the hot path
use bytes::Bytes;

pub fn process_batch(records: &[Bytes]) -> Vec<ProcessedRecord> {
    records
        .par_iter()  // Rayon parallel iterator
        .filter_map(|record| {
            // Zero-copy deserialization
            let parsed = parse_record(record)?;
            // No GC pauses during batch processing
            Some(transform(parsed))
        })
        .collect()
}

Go's garbage collector can introduce pauses during large batch processing. These pauses are usually sub-millisecond, but at high throughput they accumulate. Rust processes the same data without any GC pauses.

Pattern 2: Memory-Constrained Environments

Container memory comparison (same workload):

Go service:
  Base memory: 30-50 MB (runtime + GC)
  Working set: 150-400 MB (depends on heap pressure)
  Peak (GC cycle): 600+ MB (temporary 2x heap for GC)

Rust service:
  Base memory: 2-5 MB (minimal runtime)
  Working set: 50-80 MB (exactly what's needed)
  Peak: 90 MB (predictable, no GC spikes)

For Kubernetes deployments where you're packing dozens of services onto nodes, the memory savings from Rust translate directly to higher pod density and lower node costs.

Pattern 3: Latency-Sensitive Paths

For services where P99 latency matters — payment processing, real-time bidding, game servers, financial trading — Go's GC pauses create a long tail:

Go P99 latency distribution:
  P50: 5ms
  P90: 15ms
  P99: 45ms    ← GC pause impact
  P99.9: 120ms ← Major GC cycle

Rust P99 latency distribution:
  P50: 2ms
  P90: 8ms
  P99: 12ms    ← Predictable, no GC
  P99.9: 18ms  ← No surprises

The Practical Rust Backend Stack (2026)

Web Framework: Axum

Axum is the de facto standard for Rust web services:

use axum::{
    Router, Json,
    extract::{Path, State},
    routing::{get, post},
};
use sqlx::PgPool;
use serde::{Deserialize, Serialize};

#[derive(Clone)]
struct AppState {
    db: PgPool,
}

#[derive(Serialize)]
struct User {
    id: i64,
    name: String,
    email: String,
}

#[derive(Deserialize)]
struct CreateUser {
    name: String,
    email: String,
}

async fn get_user(
    State(state): State<AppState>,
    Path(id): Path<i64>,
) -> Result<Json<User>, AppError> {
    let user = sqlx::query_as!(User, "SELECT id, name, email FROM users WHERE id = $1", id)
        .fetch_one(&state.db)
        .await?;
    Ok(Json(user))
}

async fn create_user(
    State(state): State<AppState>,
    Json(input): Json<CreateUser>,
) -> Result<Json<User>, AppError> {
    let user = sqlx::query_as!(User,
        "INSERT INTO users (name, email) VALUES ($1, $2) RETURNING id, name, email",
        input.name, input.email
    )
    .fetch_one(&state.db)
    .await?;
    Ok(Json(user))
}

#[tokio::main]
async fn main() {
    let pool = PgPool::connect(&std::env::var("DATABASE_URL").unwrap())
        .await
        .unwrap();

    let state = AppState { db: pool };

    let app = Router::new()
        .route("/users/:id", get(get_user))
        .route("/users", post(create_user))
        .with_state(state);

    let listener = tokio::net::TcpListener::bind("0.0.0.0:3000").await.unwrap();
    axum::serve(listener, app).await.unwrap();
}

Type-safe extractors, compile-time SQL verification (via sqlx), and async-first design. The compile-time checks catch bugs that would be runtime panics in Go.

Database: SQLx

SQLx provides compile-time verified SQL queries:

// This query is verified against your database at compile time
// If the table structure changes, this won't compile
let users = sqlx::query_as!(
    User,
    r#"
    SELECT id, name, email, created_at
    FROM users
    WHERE active = true
    ORDER BY created_at DESC
    LIMIT $1
    "#,
    limit
)
.fetch_all(&pool)
.await?;

If your SQL doesn't match your database schema, the code doesn't compile. Zero runtime SQL errors in production.

Async Runtime: Tokio

Tokio is the async runtime that powers most Rust web services:

// Tokio: work-stealing async runtime
// Automatically distributes work across CPU cores
#[tokio::main(flavor = "multi_thread", worker_threads = 4)]
async fn main() {
    // Spawn concurrent tasks
    let (users, orders, analytics) = tokio::join!(
        fetch_users(),
        fetch_orders(),
        fetch_analytics(),
    );
    // All three run concurrently on the thread pool
}

Serialization: Serde

Serde is blazingly fast and zero-copy where possible:

use serde::{Deserialize, Serialize};

#[derive(Serialize, Deserialize)]
struct ApiResponse<T: Serialize> {
    data: T,
    metadata: ResponseMetadata,
}

#[derive(Serialize, Deserialize)]
struct ResponseMetadata {
    request_id: String,
    timestamp: chrono::DateTime<chrono::Utc>,
    #[serde(skip_serializing_if = "Option::is_none")]
    pagination: Option<Pagination>,
}

// Benchmark: serde_json processes 1GB of JSON in ~2 seconds
// Go's encoding/json: ~8 seconds for the same data

The Rewrite Decision Framework

Not every Go service should be rewritten in Rust. Here's when it makes sense:

Rewrite When:

1. The service is CPU-bound and latency-sensitive: Payment processing, real-time analytics, game servers, trading systems
2. Memory is the constraint: You're hitting Kubernetes memory limits and scaling horizontally adds cost
3. You need predictable latency: P99 SLA requirements where GC pauses are unacceptable
4. The service is stable and well-understood: Rewriting a service with unclear requirements is a waste regardless of language
5. The team has Rust experience (or is willing to invest): A Rust rewrite by Go developers with no Rust experience will take 3-4x longer initially

Keep Go When:

1. Rapid iteration matters more than performance: Startups, prototypes, MVP development
2. The service is I/O-bound: If you're mostly waiting on database queries or API calls, Go and Rust perform similarly
3. Team velocity is the priority: Go's simplicity means faster onboarding and larger contributor pool
4. The service is a CLI or DevOps tool: Go's single-binary deployment and cross-compilation are hard to beat for CLIs

The Hybrid Approach (Most Common)

Most organizations don't rewrite everything. They identify the 3-5 services where performance matters most and rewrite those:

Microservice Architecture:

┌─────────────────────────────────────────┐
│ API Gateway (Go) — routing, auth, rate  │
│ limiting. I/O bound, Go is fine.        │
├─────────────────────────────────────────┤
│ User Service (Go) — CRUD operations,    │
│ moderate traffic. Go is fine.           │
├─────────────────────────────────────────┤
│ Payment Service (Rust) — latency-       │
│ sensitive, high throughput. Rust wins.  │
├─────────────────────────────────────────┤
│ Analytics Pipeline (Rust) — batch       │
│ processing 100M+ records. Rust wins.   │
├─────────────────────────────────────────┤
│ Notification Service (Go) — async       │
│ email/SMS. I/O bound, Go is fine.      │
└─────────────────────────────────────────┘

Migration Tips from Teams Who've Done It

Tip 1: Start with a Non-Critical Service

Don't rewrite your payment system first. Start with an internal tool, a batch processor, or a non-critical microservice. Let the team build Rust muscle memory on something that won't page them at 3 AM.

Tip 2: The Ownership System Takes 2-4 Weeks

Every Go developer hits the "fighting the borrow checker" phase. It lasts 2-4 weeks. Then something clicks, and the borrow checker becomes your best friend — it catches bugs at compile time that would be race conditions in production.

Tip 3: Embrace the Type System

// Instead of Go's error-prone string types:
// type UserId string (Go — nothing stops you from mixing UserIds and OrderIds)

// Rust: newtype pattern prevents mixing types
struct UserId(i64);
struct OrderId(i64);

// This won't compile — UserId and OrderId are different types
// fn process(user: UserId, order: OrderId) { ... }
// process(order_id, user_id) // COMPILE ERROR

Tip 4: Use Docker Multi-Stage Builds

# Build stage
FROM rust:1.76-slim AS builder
WORKDIR /app
COPY . .
RUN cargo build --release

# Runtime stage — minimal image
FROM debian:bookworm-slim
RUN apt-get update && apt-get install -y ca-certificates && rm -rf /var/lib/apt/lists/*
COPY --from=builder /app/target/release/myservice /usr/local/bin/
EXPOSE 3000
CMD ["myservice"]

# Final image: ~25MB (vs ~250MB for Go with Alpine)

Tip 5: Compile Times Are Real

Full Rust builds for a medium-sized project take 3-5 minutes. Incremental builds take 5-15 seconds. Use:

• cargo check instead of cargo build during development
• sccache for shared compilation cache
• cargo-nextest for faster test execution
• Consider mold linker for 2-3x faster linking

The Broader Trend: Rust Beyond Backends

Rust's enterprise adoption isn't limited to backends:

• PL/Rust in PostgreSQL 18: Write database functions in Rust for native performance
• WebAssembly: Rust is the primary language for WASM server-side (Spin, Fermyon)
• Cloud infrastructure: Cloudflare Workers, AWS Lambda (custom runtime), Fastly Compute
• CLI tools: ripgrep, fd, bat, delta — Rust CLIs replacing Unix classics
• Embedded/IoT: Embassy framework for async embedded Rust

24.3% of Rust adoption is in cloud infrastructure — the single largest use case.

The Bottom Line

Rust in production isn't about Rust being "better" than Go, Python, or Java in every dimension. It's about Rust being measurably better in specific, high-value dimensions: memory efficiency, latency predictability, and CPU utilization.

Grab's 70% cost reduction is the headline, but the real story is the predictability. No GC pauses. No memory spikes. No latency surprises. For services where those properties matter — and every engineering team has a few — Rust is the clear choice in 2026.

The question isn't whether to use Rust. It's which services to rewrite first.