I Asked Expert Programmers to Max Out a $12 Server

Summary

The video reports the results of a community challenge to maximize a simple social-network API on a $12 server with one shared CPU core, 2 GB RAM, and 50 GB storage. The best submission sustained 64,000 concurrent users, far above the host’s previous best of about 14,000.

Benchmark setup

Each implementation provided the same five-endpoint API, backed by SQLite in the application process. External databases, Redis, and separate caching servers were disallowed. Authenticated requests had to verify token signatures, and writes had to be committed before success was returned.

K6 simulated users reading feeds, opening posts, liking them, and creating posts. To pass, an implementation had to sustain a load for five minutes with under 1% errors, 95% of requests under 500 ms, and 99% under one second. The fastest tests required four virtual machines to generate load because one load generator became a bottleneck.

Results and notable techniques

Implementation Peak reported users Notable approach Ruby on Rails 3,000–3,500 Conventional framework implementations Optimized Ruby 14,000 Iodine server, YJIT, and SQLite generating JSON directly Erlang 15,000 Cowboy, lightweight processes, one scheduler, and SQLite-generated JSON Python 22,000 Removed much of FastAPI/Starlette’s request-processing overhead; used SQLite, uvloop, and orjson Go 22,000 A single database-owning routine batched writes using group commit; connection limits became a bottleneck C# 32,000 Used Kestrel’s lower-level interfaces and reduced allocations with reusable buffers and stack memory Fortran 38,000 Used libmicrohttpd for HTTP, SQLite for JSON and token-validation queries, and group commit PHP 40,000 Swoole kept the application running persistently, avoiding per-request startup; PHP JIT was enabled C 46,000 Used Linux io_uring, an application-optimized SQLite build, and a more efficient feed query TypeScript on Bun 47,000 Replaced the general HTTP server with a specialized raw-TCP implementation; SQLite returned JSON as bytes Rust with Axum 43,000 Batched database work, but memory use and connection handling limited results Zig 61,000 Used uSockets and group commit; a hard-coded persistent-connection limit and reconnects restricted it Optimized Rust 64,000 Used io_uring, batched events and writes, and low-overhead socket handling; used under 100 MB RAM C++ 64,000 Single-threaded event loop and SQLite cache/checkpoint changes; high-end latency was worse than Rust’s

The 64,000-user ceiling was largely imposed by the Linux connection-tracking table, which began dropping packets beyond that range under the benchmark’s fixed rules. Rust reached the limit with about half the CPU capacity still available, so its true maximum was not established. C++ tied on user count but had higher P99 latency (910 ms versus Rust’s 224 ms) and used more CPU.

Main performance lessons

• Remove unnecessary layers: Most of the fastest submissions served HTTP directly rather than routing traffic through Nginx. Several also bypassed general-purpose framework middleware and routing.
• Keep database work lean: Many implementations reused prepared queries and a single SQLite connection.
• Let SQLite produce JSON: Returning database-generated JSON avoided creating application objects and serializing them again.
• Batch writes with group commit: Combining multiple writes into one transaction reduced database overhead while still waiting for the commit before reporting success.
• Reduce allocations and system-call overhead: Reusable buffers, low-level event loops, and io_uring helped avoid work on a CPU-limited machine.
• Architecture can matter more than language: For example, a stripped-down Python implementation doubled the performance of a more conventional FastAPI version.

Trade-offs and caveats

These results came from highly specialized implementations, not necessarily production-ready services. Some replaced general HTTP handling with custom code; the Rust winner used substantial unsafe code, and the C++ winner put more than 1,300 lines into one file. Such approaches can make maintenance, security, portability, and future changes harder.

The C++ result also used SQLite’s WAL mode with synchronous set to “normal,” which may acknowledge a commit without guaranteeing it survives sudden power loss. More generally, group commits require careful handling of transaction failures and request scheduling. The benchmark also prohibited kernel tuning, so its connection-table limit remained in place.

Technical walkthroughs in the video

The video is primarily a benchmark review and implementation analysis, rather than a step-by-step coding tutorial. It walks through the submissions by language, compares their performance, and explains techniques such as group commit, SQLite-generated JSON, io_uring, framework bypasses, and allocation reduction.

Main speaker/source: Arjay McCandless, presenting the benchmark and analysis. The implementations and optimization ideas came from community challenge submissions; the code was made available in the challenge repository.