High-Throughput Rust API
publishedOptimized for 100K+ RPS with sub-millisecond p99 latency
A performance-first Rust stack for APIs that need extreme throughput. Axum on Tokio with careful connection pooling, zero-copy serialization, and Linux-specific optimizations. Suitable for real-time bidding, game backends, or financial data feeds.
Component Matrix
Why This Exists
Why This Stack Exists
When your API serves real-time bidding, game state, or financial data, every microsecond matters. This stack is designed for teams that have already outgrown Go or Java and need predictable, allocation-free hot paths.
Rust gives us the control needed to eliminate GC pauses, minimize allocations, and use Linux kernel features like io_uring directly.
Tradeoffs
Tradeoffs
- High complexity: Performance optimization requires deep systems knowledge
- Specialist hiring: Need engineers comfortable with unsafe Rust and systems programming
- Linux-specific: Some optimizations (io_uring) don't work on macOS
- Premature optimization risk: Most APIs don't need this level of tuning
- Testing difficulty: Load testing at 100K+ RPS requires dedicated infrastructure
Claims (4)
This stack can sustain 200K+ RPS on a single 8-core machine with p99 under 2ms.
ScyllaDB is a better fit than PostgreSQL for read-heavy, low-latency workloads at this scale.
Most APIs do not need this level of optimization and would be better served by a simpler stack.
This stack is not appropriate for teams without performance engineering experience.
Evidence (7)
Coralogix: PostgreSQL 30s queries → ScyllaDB 86ms (349x faster), P99 < 1ms at 10K writes/sec
strongCoralogix migrated from PostgreSQL to ScyllaDB: queries went from 30s to 86ms (349x faster). P99 write latency consistently below 1ms at 10K writes/sec on a 3-node cluster (8 vCPU, 32GB each). However, this was a telemetry/observability workload — well-suited to ScyllaDB's append-heavy model.
HN: "Postgres is exactly the database you want when desperately searching for product-market fit"
moderateHacker News discussion with critical counter-evidence: Multiple engineers returned from ScyllaDB to "postgres + redis because it was cheaper." ScyllaDB's Cassandra data model "heavily dictates query performance" and requires upfront schema design — poor fit for evolving startup schemas. No transactions, joins, or flexible querying.
TechEmpower Framework Benchmarks Round 22 — industry standard comparison
strongThe industry-standard multi-framework benchmark suite. Round 22 results show Rust frameworks competitive at the top for plaintext and JSON serialization, but the gap narrows significantly for database-backed queries. Context matters: "200K+ RPS" requires specifying what the handler actually does.
Sharkbench: Axum 21K RPS, 1.6ms median latency, 8.5MB memory on Ryzen 7
strongSharkbench (Ryzen 7 7800X3D, August 2025): Axum at 21,030 RPS with 1.6ms median latency, stability ratio (median/p99) of 71.96%, using only 8.5MB memory. Demonstrates Rust's memory efficiency but shows realistic throughput is much lower than theoretical max.
TechEmpower: Axum ~400K RPS optimized, ~43K with idiomatic SQLx (not 200K)
strongTechEmpower benchmarks: Axum reaches ~400K RPS for simple PostgreSQL queries using shared-nothing architecture (one Tokio runtime per thread). However, "most idiomatic" Axum with standard SQLx connection pooling drops to ~43K RPS — underperforming Go, PHP, and Java. The 200K+ claim is realistic only for lightweight handlers without DB access.
Go gets 80% of Rust speed with 20% of the effort — Bitfield Consulting analysis
moderateBitfield Consulting: Go described as an "80%-language" — never as fast as Rust, but gets to 80% of Rust speed with 20% of the mental effort. For I/O-heavy services (web APIs, DB queries), Go "feels fast enough." Rust shines for CPU-bound work, memory-constrained environments, and safety-critical systems.
99% of API request time is I/O wait — opportunity cost of premature optimization
moderate"Optimizing Python won't help when 99% of your request time is waiting for external services, and rewriting everything in Rust will take months while competitors ship new features. The real cost of premature optimization is opportunity cost." This contextualizes when high-throughput Rust stacks are actually needed.