Viktor.comAn AI coworker that actually does the work
Promoted
The 500MB Club Challenge
2 CPUs. 500MB RAM. One real Pi. Prove your language.
14 followers
2 CPUs. 500MB RAM. One real Pi. Prove your language.
14 followers
Most backend benchmarks run on generous cloud boxes nobody deploys to. This one doesn't: a write-heavy telemetry service (GPS/battery/accel data) has to run — LB, 3 API replicas, storage — inside 2 CPUs and 500MB RAM total, on a real Raspberry Pi. Open, language-agnostic: fork it, implement the API, ship a Docker image, submit a PR. Scored on efficiency, capacity, tail latency, resilience, stability. Sponsored by Ardan Labs, JetBrains, GopherCon Latam. Deadline: July 26.
Genuinely curious how scoring works when language runtimes vary so wildly. Like would a Rust implementation get penalized because it leaves headroom that a Go or Node setup just can't, or is the scoring pure black-box against the four metrics?
@kezibangevtcuf Rust should score higher than Go on efficiency and tail latency, because Rust runtimes genuinely can do that on this workload. Nothing in the scoring penalizes Rust for leaving headroom. The curves saturate at 1.0, you can't earn more than 1.0 in a metric by being 10x better than the best point. That saturation is deliberate: without it, a submission that's absurdly fast on one trivial metric would dominate the weighted average and mask being mediocre elsewhere. Winning requires being good across multiple dimensions.
You can get how scoring works here.
How is the scoring actually weighted — does efficiency matter more than raw throughput, or do they get balanced somehow when one tanks the other?
@zlemmld5 On the "does one tank the other" question — no, there's no coupling. The formula is a flat weighted mean:
score = 100 × Σ(weight[d] × dim[d]) / Σweight[d]
So an implementation can be extremely lean at 200 RPS (great efficiency score) but hit its knee early once load ramps (weak capacity score) — or the reverse, something that idles a bit heavier at low load but scales further before breaking. Nothing in the math forces these to move together; they're two independent bets that both happen to be weighted highest because the docs treat them as the actual "500MB Club" differentiators, with everything else (latency, resilience, stability) treated more as pass/fail guardrails with tight clips so they can't dominate.
running the full stack on a real pi is the kind of constraint that actually exposes the sloppy stuff in your code. love that it's open and language agnostic, makes it feel like a real community challenge rather than a marketing stunt.
love how it forces you to actually respect the constraints of a pi instead of pretending your laptop is prod. the scoring on tail latency and stability is a nice touch too.
finally a benchmark that actually reflects what production looks like on tiny boxes. the rpi constraint makes it way more honest than synthetic cloud tests, and i love that the scoring includes resilience not just raw speed.