458 req/s on a €4/month ARM VPS — with Postgres and Redis on the same box

Most load test results you see online are from localhost benchmarks or over-provisioned cloud instances. I wanted to know what a real .NET 10 API could handle on the kind of server a bootstrapped SaaS product would actually run on — a Hetzner CAX11: 2 Ampere ARM vCPUs, 4GB of RAM, about €4 a month. And not a dedicated API node either. The API, PostgreSQL, and Redis all ran on that one box, the way an early-stage product actually deploys.

The setup

I used the Shopilent e-commerce backend as the test subject — it's open source and representative of a real production workload: PostgreSQL, EF Core, JWT auth, multi-tenancy, background jobs. The load was generated from a separate Hetzner instance in the same datacenter to eliminate network latency as a variable.

import http from 'k6/http';
import { check } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },   // ramp up
    { duration: '5m', target: 400 },   // sustained load
    { duration: '2m', target: 600 },   // push to find ceiling
    { duration: '1m', target: 0 },     // ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'],
    http_req_failed: ['rate<0.01'],
  },
};

What I optimised

• —Response caching on read-heavy endpoints with L1/L2 cache (in-memory + Redis)
• —EF Core query optimisation — compiled queries, split queries for N+1 elimination
• —Connection pool tuning — Npgsql default pool size increased to match concurrency
• —Background job queue kept isolated from the API process

The result

458 req/s sustained, p95 latency under 180ms, error rate 0.0%. The ceiling was memory, not CPU — at 600 req/s the box started swapping, which is what you would expect when the API, Postgres, and Redis are all competing for the same 4GB. The fix is more RAM, or moving the database off the box. Not more code.

For context: 458 req/s is roughly 1.6 million requests per hour — on a €4/month ARM box that was also running its own database and cache. The point isn't that you'll need this throughput. It's that the boring, proven stack has far more headroom on cheap hardware than people assume, and that your infrastructure bill is not the thing that will hold you back.