We Reran Amber V2's Router on a $4 DigitalOcean Droplet

Here is the correction first: Amber's old 55.7x router headline did not come from a cloud run, and it should not be repeated as a general Amber V2 performance claim.

The underlying router work is real. The old evidence was not strong enough for the way we described it. We have now rerun the released Amber V2 beta.4 router against amber_router 0.4.4 on DigitalOcean's smallest $4 Basic Droplet, with a corrected workload and every trial preserved.

What had actually run in the cloud

Amber already had credible hosted performance evidence, but three different benchmarks had been getting blended into one story:

• The original router table was an in-process microbenchmark on an unspecified local machine. Its notes recorded Crystal 1.18.2, but not the CPU, memory, provider, or raw paired trials.
• An April 21 Amber 1.4-versus-V2 HTTP comparison ran on DigitalOcean, but the application server was an eight-vCPU CPU-optimized Droplet—not the smallest target.
• The July 17 mixed-application result and August 11 website result did use the exact s-1vcpu-512mb-10gb size. Those are whole-HTTP capacity tests, not a before-and-after test of the two router engines.

So the narrow question—how the released V2 router compares with Amber 1.x's router on that same tiny server—was still unanswered.

The replacement test

The measured target was DigitalOcean Basic s-1vcpu-512mb-10gb in NYC3: one shared DO-Regular vCPU, 512 MiB advertised memory, 469,236 KiB visible to Linux, no swap, and a 10 GiB disk. DigitalOcean's API listed it at $4 per month when the test ran on August 13, 2026.

We compiled two separate static x86-64 binaries with Crystal 1.21.0 using --release --no-debug --static:

• before: amber_router 0.4.4, commit 8f05718a4d49411e664f57a7f162565ce25fab75;
• after: Amber 2.0.0-beta.4, commit a2128cdb4fef07025e0cc1c1578d4c807ae6c274.

Both binaries received the same 100-, 1,000-, and 10,000-route tables. The mix was 60% fixed, 25% variable, 10% variable with a fixed suffix, and 5% glob. Each glob route had a distinct match shape. We tested fixed, variable, glob, and not-found lookups with two seconds of warmup and five seconds of measurement per process.

Every scenario ran as seven before-and-after pairs. Odd repetitions ran the old router first; even repetitions ran V2 first. The result for each scenario is the median of its seven same-repetition V2/old ratios. That pairing matters on shared cloud CPUs because both absolute rates can move when neighboring workloads change.

Results

Amber V2 was faster in all 84 individual pairs. Every scenario's median bootstrap interval stayed above 1.0x, and alternating order did not change the story: the geometric mean was 1.90x when the old router ran first and 1.87x when V2 ran first.

Across the 12 scenario medians, the geometric-mean speedup was 1.89x.

Unit: every rate in this table is an in-process router lookup per second, not a completed HTTP request per second.

The 100-route rows are the best shorthand for an ordinary application: fixed, variable, and glob lookup medians improved by 44% to 58%, while the tested not-found path improved by 131%. At the intentionally extreme 10,000-route tier, the corrected unique-glob lookup improved by 354%.

The intervals are deterministic percentile-bootstrap intervals over seven paired ratios. They describe the repeatability of this bounded run; they are not a promise about every cloud host or application.

Why 55.7x changed

The old glob generator varied the glob parameter name but reused only five effective URL shapes. At the 10,000-route tier, its 500 declared glob routes became 100 terminal entries behind each of those five shapes. The old test really did measure that duplicate-route edge case, but the result was described as though it represented 10,000 unique routes.

The replacement generator gives every glob route a unique prefix and looks up the last one. That is a cleaner test of a large route table and a harder test of the old router's linear child scan. It also produces a much smaller, much more defensible number than 55.7x.

The audit found two other historical-label problems. The old generator called 10% of its routes "constrained" without ever passing a regular-expression constraint, and the cross-framework script loaded stored Amber results while running only the third router fresh with a different route generator. We have corrected those descriptions and marked that cross-framework output as historical mixed-provenance material, not a ranking.

What changed in V2

The Amber 1.x router kept fixed, variable, glob, and terminal children together in one array. Matching scanned that mixed array and performed runtime type checks along the way. Beta.4 separates those structures: fixed segments use a hash, variable segments stay in a small array, a glob gets its own slot, and terminal leaves live separately as value types.

V2 also registers route segments by index instead of repeatedly shifting an array and splits paths into a pre-sized array in one pass. Registration is recorded by this benchmark but excluded from timed lookup throughput.

One earlier explanation said RoutedResult became a struct. It did not; RoutedResult remains a class in beta.4. The performance gain does not require us to overstate the implementation.

Router lookups are not HTTP requests

These rates measure only RouteSet#find. They exclude sockets, HTTP parsing, middleware, controller dispatch, ECR rendering, JSON serialization, databases, TLS, reverse proxies, and the public network. Millions of router lookups per second must never be presented as millions of HTTP requests per second.

For complete application behavior, use the separately documented hosted results: the 26,271-byte Amber website homepage sustained a 5,907 requests per second median on this size, while a deterministic mixed 1,000-route JSON workload sustained 21,795 requests per second. Those workloads answer a different question and keep their own limitations.

Inspect and reproduce it

The machine-readable summary contains the target, source revisions, compiler, binary checksums, workload, paired ratios, intervals, and limitations. The raw 168 trials and machine snapshot are published beside it. The harness lives in Amber's benchmarks/router_cloud/ directory.

The honest conclusion is better than the old headline: Amber V2's released router is measurably faster on the smallest server used for these published experiments, the result survives paired cloud trials, and you can inspect every number we used to say so.