Python vs Go vs Rust

I wanted to see what switching from Python to Go or Rust actually buys you when an API spends most of its time waiting on databases and other services. So I built the same small storefront API in all three and gave each one the same CPU, memory, and load.

The result I found most useful was how little the response times changed at equal load, while CPU and memory usage were quite different. Below are the measurements, the setup, and the code behind them.

The comparison is between Python with FastAPI and uvicorn, Go with net/http, and Rust with axum and tokio. Each service gets 2 CPUs and 512 MiB of memory, with a mock upstream latency of 30 ± 10 ms.

Benchmark snapshot: api-lang-bench, commit 0c751c1. Report generated September 13, 2026.

What the numbers say #

• At a fixed 500 requests per second mixed load, p50 latency differs by only 0.9 ms across the three: Python 24.8 ms, Go 23.9 ms, and Rust 24.0 ms. Waiting on the upstream service dominates this I/O-bound workload.
• CPU used at that load, as a percentage of the container limit: Rust 4%, Go 6%, Python 17%. Relative to Rust, the report measures Python at 3.9× and Go at 1.4×. The displayed percentages are rounded; the ratios use the underlying measurements.
• Memory under load: Rust 6 MiB, Go 15 MiB, Python 119 MiB. Relative to Rust: Python 19.8×, Go 2.5×.
• Framework floor: throughput on /health with a ramp to 50 virtual users reaches 50,872 requests/s for Python, 120,279 for Go, and 131,200 for Rust. Relative to Python, that is 2.4× for Go and 2.6× for Rust.
• Under a stress profile ramping from 500 to 2,000 requests/s, all three averaged 1,249 achieved requests/s. Python recorded 0.01% failed requests and 9 dropped iterations; Go recorded 0.00% and 2; Rust recorded 0.00% and 3. Their p95 latencies were 40.5, 39.5, and 39.4 ms respectively.
• This stress run does not establish each implementation’s saturation point. To find that point, raise RATE or lower SVC_CPUS and repeat the profile. Python has the least headroom by measured CPU usage in this comparison.

The setup #

The same six endpoints exercise Postgres queries, Redis cache-aside access, upstream HTTP calls, JSON parsing, and response serialization. The mixed workload combines 40% browse, 25% search, 20% home, and 15% checkout. /health provides a separate framework-floor measurement without application I/O.

One service runs at a time. Postgres, Redis, the upstream mock, and k6 are outside the service’s CPU and memory limits.

The source report records a successful make parity check across 15 of 15 cases, with byte-identical JSON for identical inputs. That gives the timing comparison a useful starting point: the implementations returned the same results for the checked cases.

Machine and Docker environment #

These host details were probed when the report was generated; they were not stored with the individual runs. The service, database, cache, upstream mock, and load generator all share this VM, even though only the service has explicit resource limits.

Runtimes and libraries #

The artifact lists these runtime versions and dependencies from the lockfiles:

Shared settings #

Python uses one uvicorn worker per CPU, with connection pools divided between workers. Go uses a single process with cgroup-aware GOMAXPROCS. Rust uses tokio worker threads matching the CPU allowance and a multiplexed Redis connection, so REDIS_POOL_SIZE does not apply to Rust in the same way.

Reading CPU correctly: the charts and article tables show average CPU as a percentage of the two-CPU container limit, where 100% means the whole allowance. The downloadable results also retain the original docker stats host-core percentages, where 200% means two full cores. Normalization uses the unrounded measurements before display rounding.

All memory figures in the article tables are average container memory under load, in MiB. Python’s figure includes its worker processes.

The same endpoint, three ways #

Numbers only tell part of the story. Here are the actual handlers from the report, so you can compare what each implementation does. Shared helpers and imports are omitted; these are excerpts from the benchmark services, not standalone programs.

Open an endpoint to see its Python, Go, and Rust versions.

@router.get("/products/{product_id}")
async def get_product(product_id: str, request: Request) -> Response:
    try:
        pid = int(product_id)
    except ValueError:
        pid = 0
    if pid < 1:
        raise HTTPException(400, "bad id")
    st = request.app.state
    key = f"product:{pid}"
    cached = await st.cache.get(key)
    if cached is not None:
        return Response(cached, media_type="application/json")
    product = await st.store.get(pid)
    if product is None:
        raise HTTPException(404, "product not found")
    body = orjson.dumps(product)
    await st.cache.set(key, body)
    return Response(body, media_type="application/json")

func (d Deps) getProduct(w http.ResponseWriter, r *http.Request) {
	id, err := strconv.Atoi(r.PathValue("id"))
	if err != nil || id < 1 {
		writeErr(w, http.StatusBadRequest, "bad id")
		return
	}
	ctx := r.Context()
	key := "product:" + strconv.Itoa(id)
	if b, err := d.Cache.Get(ctx, key); err == nil {
		writeRaw(w, b)
		return
	}
	p, err := d.Store.Get(ctx, id)
	if errors.Is(err, store.ErrNotFound) {
		writeErr(w, http.StatusNotFound, "product not found")
		return
	}
	if err != nil {
		writeErr(w, http.StatusInternalServerError, "db: "+err.Error())
		return
	}
	b, _ := json.Marshal(p)
	if err := d.Cache.Set(ctx, key, b); err != nil {
		log.Printf("cache set: %v", err)
	}
	writeRaw(w, b)
}

async fn get_product(State(s): State<AppState>, Path(id): Path<String>) -> ApiResult<Response> {
    let id: i32 = match id.parse() {
        Ok(n) if n >= 1 => n,
        _ => return Err(ApiError::BadRequest("bad id".into())),
    };
    let key = format!("product:{id}");
    if let Some(b) = s.cache.get(&key).await? {
        return Ok(raw_json(b));
    }
    let p = s.store.get(id).await?.ok_or_else(|| ApiError::NotFound("product not found".into()))?;
    let b = serde_json::to_vec(&p).expect("product serialises");
    if let Err(e) = s.cache.set(&key, &b).await {
        eprintln!("cache set: {e}");
    }
    Ok(raw_json(b))
}

@router.post("/cart/checkout")
async def cart_checkout(body: CheckoutRequest, request: Request) -> ORJSONResponse:
    st = request.app.state
    items = [checkout.Item(i.sku, i.qty) for i in body.items]
    try:
        checkout.validate(items)
        prices = await st.store.prices_by_sku([i.sku for i in items])
        receipt = checkout.subtotal(items, prices)
    except checkout.InvalidCart as e:
        raise HTTPException(400, str(e)) from e
    tax = await st.upstream.tax(receipt.subtotal_cents, "UK")
    return ORJSONResponse(checkout.with_tax(receipt, tax))

func (d Deps) checkout(w http.ResponseWriter, r *http.Request) {
	var body struct {
		Items []checkout.Item `json:"items"`
	}
	if err := json.NewDecoder(r.Body).Decode(&body); err != nil {
		writeErr(w, http.StatusBadRequest, "bad json: "+err.Error())
		return
	}
	if err := checkout.Validate(body.Items); err != nil {
		writeErr(w, http.StatusBadRequest, err.Error())
		return
	}
	ctx := r.Context()
	skus := make([]string, len(body.Items))
	for i, it := range body.Items {
		skus[i] = it.SKU
	}
	prices, err := d.Store.PricesBySKU(ctx, skus)
	if err != nil {
		writeErr(w, http.StatusInternalServerError, "db: "+err.Error())
		return
	}
	receipt, err := checkout.Subtotal(body.Items, prices)
	if err != nil {
		writeErr(w, http.StatusBadRequest, err.Error())
		return
	}
	tax, err := d.Upstream.Tax(ctx, receipt.SubtotalCents, "UK")
	if err != nil {
		writeErr(w, http.StatusBadGateway, "upstream: "+err.Error())
		return
	}
	writeJSON(w, http.StatusOK, checkout.WithTax(receipt, tax))
}

async fn cart_checkout(
    State(s): State<AppState>,
    body: Result<Json<CheckoutRequest>, JsonRejection>,
) -> ApiResult<Json<Receipt>> {
    let Json(body) = body.map_err(|e| ApiError::BadRequest(format!("bad json: {}", e.body_text())))?;
    checkout::validate(&body.items).map_err(|e| ApiError::BadRequest(e.0))?;
    let skus: Vec<String> = body.items.iter().map(|i| i.sku.clone()).collect();
    let prices = s.store.prices_by_sku(&skus).await?;
    let receipt = checkout::subtotal(&body.items, &prices).map_err(|e| ApiError::BadRequest(e.0))?;
    let tax = s.upstream.tax(receipt.subtotal_cents, "UK").await?;
    Ok(Json(checkout::with_tax(receipt, tax)))
}

@router.get("/home")
async def home(request: Request) -> ORJSONResponse:
    """Fan-out to upstream + Postgres + Redis concurrently, then merge."""
    st = request.app.state
    featured, top, banner = await asyncio.gather(
        st.upstream.search("featured"), st.store.top(10), st.cache.get("banner"),
    )
    return ORJSONResponse({"featured": _to_results(featured["hits"]), "top_products": top, "banner": (banner or b"").decode()})

// home fans out to all three dependencies concurrently and merges.
func (d Deps) home(w http.ResponseWriter, r *http.Request) {
	g, ctx := errgroup.WithContext(r.Context())
	var (
		featured upstream.SearchResponse
		top      []store.Product
		banner   []byte
	)
	g.Go(func() (err error) { featured, err = d.Upstream.Search(ctx, "featured"); return })
	g.Go(func() (err error) { top, err = d.Store.Top(ctx, 10); return })
	g.Go(func() (err error) {
		banner, err = d.Cache.Get(ctx, "banner")
		if errors.Is(err, cache.ErrMiss) {
			banner, err = []byte(""), nil
		}
		return
	})
	if err := g.Wait(); err != nil {
		writeErr(w, http.StatusBadGateway, err.Error())
		return
	}
	writeJSON(w, http.StatusOK, homeResponse{Featured: toResults(featured.Hits), TopProducts: top, Banner: string(banner)})
}

/// Fan-out to upstream + Postgres + Redis concurrently, then merge.
async fn home(State(s): State<AppState>) -> ApiResult<Json<HomeOut>> {
    let (featured, top, banner) = tokio::try_join!(
        async { s.upstream.search("featured").await.map_err(ApiError::from) },
        async { s.store.top(10).await.map_err(ApiError::from) },
        async { s.cache.get("banner").await.map_err(ApiError::from) },
    )?;
    let banner = String::from_utf8_lossy(&banner.unwrap_or_default()).into_owned();
    Ok(Json(HomeOut { featured: to_results(featured.hits), top_products: top, banner }))
}

Every run, by scenario and load shape #

The constant profile holds a fixed arrival rate. The ramp profile increases virtual users. The stress profile increases the arrival rate from RATE to four times that value. Latency values below are milliseconds; CPU values are rounded percentages of the container limit.

Mixed workload: 500 requests/s #

SCENARIO=mixed, PROFILE=constant, RATE=500, DURATION=60s.

All three recorded 0.00% failed requests and zero dropped iterations.

Framework floor: health endpoint #

SCENARIO=health, PROFILE=ramp, VUS=50, DURATION=30s. The shared configuration retains RATE=500, but this profile is driven by virtual users rather than a fixed request rate.

All three recorded 0.00% failed requests and zero dropped iterations.

Mixed workload: 1,500 requests/s #

SCENARIO=mixed, PROFILE=constant, RATE=1500, DURATION=60s.

All three recorded 0.00% failed requests. Python had 4 dropped iterations; Go and Rust had zero.

Mixed workload: stress #

SCENARIO=mixed, PROFILE=stress, RATE=500, DURATION=60s. The arrival-rate target ramps from 500 to 2,000 requests/s.

The 1,249 requests/s figure is the achieved average over the ramp, not its peak target. Failed requests and dropped iterations are separate measurements; both matter when interpreting the result.

Search: 500 requests/s #

SCENARIO=search, PROFILE=constant, RATE=500, DURATION=60s. This scenario waits on upstream HTTP, then parses and reshapes the response.

All three recorded 0.00% failed requests and zero dropped iterations.

How to read these results #

These are relative measurements on one machine. The services ran inside Docker Desktop on macOS, which uses a Linux VM. Compare the implementations within this setup; the figures are not production capacity estimates.

At equal load, the I/O-bound endpoints have very similar latency. CPU and memory are where the implementations separate. The /health results show a different part of the picture: what happens when application I/O is removed.

There is another limit worth keeping in mind: k6 generates the load from inside the same VM. It can also bound the maximum throughput measured by the /health ramp, so those numbers are not an isolated measure of server capacity.

The tests cover these particular frameworks, libraries, worker configurations, and workloads. To establish capacity for another environment, repeat the measurements on that environment and continue the load ramp until the limits are visible.

Download the complete results for all 15 runs (CSV), including error rates, dropped iterations, raw average and maximum CPU, and idle, average, maximum, and post-load memory.