Which Programming Language Can Handle the Most Users on a $12 Server?

Summary

The video benchmarks eight backend implementations on the same $12 VPS, with one shared CPU, 2 GB of RAM, and 50 GB of storage. Each implementation served the same Twitter-style API, using Nginx and a PostgreSQL database. The goal was to compare how many simulated users each setup could support—not to find the maximum performance possible through extensive tuning.

Methodology

• The database contained 50,000 users, 500,000 posts, and just over 2 million likes.
• Simulated users followed a typical usage cycle: load a feed, open a post, and sometimes like or create a post. Each user averaged about 0.1 requests per second.
• The load increased until a backend exceeded one of these limits:
  • P95 latency of 500 ms
  • P99 latency of 1 second
  • Error rate of 1%
• Each backend was warmed up, tested to find an approximate limit, then run for a five-minute confirmation test. Implementations used the same endpoints, authentication, SQL queries, and database connection pool, with minimal optimization.

PostgreSQL benchmark results

Approximate maximum concurrent simulated users:

Backend Users Approx. requests per second Laravel with PHP-FPM 750 — Python with FastAPI/Uvicorn 2,150 200 Node.js with Express 3,250 300 Bun 4,200 389 C# with ASP.NET Core 4,400 — Java with Spring Boot 5,100 Nearly 500 Go 6,500 Over 600 Rust with Axum 6,900 640

The results are approximate; the presenter advises allowing for around 10% variation between runs. Broadly, Go and Rust were in a similar performance tier, followed by Java, C#, and Bun, then Node.js, Python, and Laravel.

Notable findings

• Bun ran nearly the same JavaScript application as Node.js and supported about 30% more users in this test.
• Python passed at 2,150 users, but at higher loads, database connection timeouts caused errors.
• PHP results varied significantly by setup. Laravel with PHP-FPM reached 750 users. Laravel Octane, which keeps the application loaded between requests, reached about 1,250. Rewriting the API in bare PHP raised the result to around 2,700. The presenter cautions that this lightweight API may disproportionately expose Laravel’s per-request overhead.
• C# reached about 4,400 users, but the presenter found that the Npgsql database driver was issuing many DISCARD ALL commands. This illustrated how driver or framework defaults can affect results, not just the language itself.
• At the Go and Rust limits, PostgreSQL—not the application code—had become the main bottleneck. The database used about 60% of the CPU, while the application used roughly 22–24%.

Follow-up test with SQLite

To examine the database bottleneck, the presenter replaced PostgreSQL with SQLite in write-ahead log mode and retested the three fastest backends:

• Java: 10,250 users, up from 5,100.
• Go: 11,750 users, up from 6,500.
• Rust: 14,050 users sustained for five minutes, at about 1,300 requests per second. A 15,000-user test failed.

The presenter frames this as a controlled test of database-process overhead, not a general recommendation to replace PostgreSQL with SQLite; the two have different trade-offs.

Overall takeaway

Language and framework choices can make a substantial difference in this particular setup, but the ranking is not a universal measure of language performance. Framework overhead, runtime behavior, database drivers, and process models all influenced the outcomes. As the backend got faster, PostgreSQL became the limiting factor, so reducing database overhead mattered more than further tuning the application language.

Review and source

This is a benchmark and technical analysis, not a step-by-step programming tutorial. It explains the test setup and compares backend performance.

Main speaker and source: Arjay McCandless, the presenter and benchmark author.