This page has two kinds of numbers:

• HTTP benchmarks — tileserver-rs and its alternatives run in Docker and serve the same fixtures under the same load. These are the numbers to compare servers with.
• In-process benchmarks — criterion micro-benchmarks of single hot functions (further down). These show where time goes inside tileserver-rs; they do not compare servers.

Test environment

Run captured 2026-10-16 against tileserver-rs:latest built from main at commit cff03152 (after v2.38.0, with CEL filtering and the LLM proxy).

• Hardware: Apple Silicon MacBook, 12 cores, Docker Desktop (ARM64 native images)
• Load tool: autocannon, 100 connections, 10 s per case (STAC: 20 connections, 30 s warmup)
• Competitors: ghcr.io/maplibre/martin:latest, maptiler/tileserver-gl:latest, ghcr.io/developmentseed/titiler:latest
• Quiet host: each group started only after benchmarks/scripts/run-quiet.sh measured the host as idle for 15 s (non-Docker processes under 120 % of one core in total, benchmark containers under 20 %, at least 25 % memory free). The measured load before and after every group is in the run's stability.log.
• Errors: 0 non-2xx responses in every case below.

Test data

The world COG is built by benchmarks/scripts/make-benchmark-cog.sh (Natural Earth, reprojected to EPSG:3857, JPEG, 5 overviews). It is not the 90 MB file used before October 2026, so COG numbers do not compare with older runs.

Summary

Average over all zoom levels of a group:

Read this before comparing PMTiles and MBTiles

The stored tiles are gzip-compressed. The PMTiles and MBTiles groups send no Accept-Encoding header:

• tileserver-rs and tileserver-gl send the stored gzip tile (Florence z12: 58 KB, content-encoding: gzip).
• martin decompresses and sends the raw tile (Florence z12: 82 KB, no content-encoding).

So these two groups do not measure the same work. The compression group sends an explicit Accept-Encoding to every server, so it compares equal work:

At the same encoding tileserver-rs and martin are within 1 % (gzip: 5 %). tileserver-rs caches brotli and zstd variants per (source, z, x, y, encoding), so re-encoding cost is paid once per tile. The April 2026 result where martin fell to 107 req/s on brotli does not hold with the current martin image.

Results by zoom level

Requests/s, average latency and P99 latency per case.

PMTiles (Florence, Italy)

martin has the best average latency, but its P99 is 2–3× higher than tileserver-rs at every zoom (z14: 320 ms vs 106 ms). At z15 tileserver-rs leads on all three numbers.

MBTiles (Zurich, Switzerland)

Same pattern as PMTiles: martin leads the average, tileserver-rs leads the tail.

PostGIS table (benchmark_points, 50,000 points)

PostGIS 3.6.4 on PostgreSQL 16.15, built from source by benchmarks/postgres/Dockerfile.

Both servers are bound by PostGIS (ST_AsMVT) at low zoom. tileserver-rs is ahead at z12–z14; its P99 at z10–z11 is worse than martin's.

PostGIS function source

Re-run after the function-source cache fix (both servers in the same run). "Before" is the first run, where tileserver-rs sent every function-source request past its tile cache.

With the cache fix tileserver-rs is within 4 % of martin on average (1,447 vs 1,502 req/s), up from 8× behind. Its P99 at z10–z12 is still about 2× martin's; that is open work. Requests that pass query parameters to the function still skip the cache, because the function output can depend on them.

COG (world RGB, JPEG overviews)

DEM terrain-RGB (Terrarium)

Encoding is byte-accurate: a round-trip decode reproduces source elevation within the encoding interval (≤0.1 m Mapbox-RGB, ≤1/256 m Terrarium).

Raster style rendering (protomaps-light, Florence)

Both use MapLibre Native. tileserver-gl is faster from z12 up.

OGC API Features

STAC

The STAC group ran, but its results are not a valid comparison: the static Sentinel-2 tiles from tileserver-rs were ~2 KB blank PNGs (the max_items = 1 scene does not cover the requested tiles), and titiler's responses averaged ~3 KB. The STAC fixture needs fixing before these numbers mean anything.

Running benchmarks

# Build the image from your checkout
docker build -t tileserver-rs:latest .

# Start every server (tileserver-rs, martin, tileserver-gl, titiler, PostGIS)
docker compose -f benchmarks/docker-compose.yml --profile all up -d

# Build the world COG fixture once (needs GDAL)
benchmarks/scripts/make-benchmark-cog.sh

# Run all groups, each only when the host is quiet
benchmarks/scripts/run-quiet.sh

# Turn a run into markdown tables
node benchmarks/scripts/summarize-run.mjs benchmarks/results/<timestamp>

Run single groups directly with the harness:

cd benchmarks
node run-benchmarks.js --type pmtiles            # or mbtiles, postgres, postgres_function,
                                                 # cog, dem, raster, ogc, stac, compression
node run-benchmarks.js --type cog --server tileserver-rs
node run-benchmarks.js --duration 30 --connections 200
node run-benchmarks.js --markdown

With pnpm 12, pass flags without --: pnpm --filter @tileserver-rs/benchmarks run bench --type pmtiles.

Quit heavy applications first and check stability.log after the run. A result measured on a busy host is not a valid result.

Feature comparison

Optimization Tips

1. Use release builds - cargo build --release is 10-50x faster than debug
2. Use PMTiles for production - cloud-native, HTTP range request friendly
3. Use MBTiles for development - easy to generate and inspect with SQLite tools
4. Enable compression - gzipped tiles reduce bandwidth significantly
5. Use CDN caching - tiles are immutable, cache with long TTLs
6. Match connections to cores - more connections than CPU cores adds overhead
7. For COG serving - use internal tiling and overviews for faster access

Raster fast-path (STAC mosaic, band math)

Added in the raster fast-path stack (commits #1-#8 merged into main 2026-04-19). Measured on a 12-core Apple M2 / 16 GB with the raster feature enabled and the default CPU baseline (x86-64-v3 via the -fast Docker tier rebuilds these with AVX-512 / SVE2).

Reproduce with:

cargo bench --bench raster --features raster

Comparison to titiler

Titiler's own benchmarks (from titiler#321 and rio-tiler's internal criteria tests) place equivalent in-memory operations in the same order of magnitude: ~1-3 ms for NDVI on a 256×256 tile, dominated by numpy+numexpr overhead. tileserver-rs lands in the same envelope with exmex (pure-Rust, ~1.5 ms) without the Python import cost; switching to an AVX-512-targeted build (:fast Docker tier) cuts these further on servers with the right CPU.

Why COG serving is fast

The COG results in the HTTP table above come mainly from overview pyramid selection: GDAL is opened with OVERVIEW_LEVEL=N, so the warp reads a pre-computed overview instead of the full-resolution raster. Other contributors: Moka-cached Dataset handles, parallel mosaic compositing with futures::join_all, and the RasterImage ndarray pipeline that keeps pixel values as floats through the mosaic layer.

What was not yet benchmarked

• Cold-path STAC /search + /vsicurl/ COG fetch: dominated by network RTT, not CPU. Typical 500-2000 ms on Element84 Earth Search; this is not part of the raster fast-path scope.
• Full mosaic pipeline with real COG reads: requires a live S3 COG and a local network, so the cold-path numbers are deferred to benches/stac_live.rs in a follow-up commit.
• GDAL Dataset moka cache hit rate: qualitative observation on demo.tileserver.app shows warm-path tiles dropping from ~2 s to ~150 ms after the cache lands, matching the arithmetic (~30 ms × 5 asset re-opens = 150 ms saved per tile).

Style-rewrite hot path

rewrite_style_for_api runs once on every GET /styles/{id}/style.json and again before every native-render request — it converts relative tile/source URLs to absolute, forwards ?key= query strings, and injects the MLT encoding hint where applicable.

Reproduce with:

cargo bench --bench styles

Sub-10 µs per call confirms style rewriting is not on the critical path of perceived latency — it's at least three orders of magnitude faster than the actual tile fetch (1-10 ms range).

MVT→MLT transcode (native mlt-core 0.11 reader)

When a client requests .mlt from an MVT source, mvt_to_mlt transcodes on the fly. As of mlt-core 0.11 this uses the native mvt::mvt_to_tile_layers reader, which decodes MVT straight into row-oriented TileLayers — replacing the previous hand-rolled GeoJSON FeatureCollection bridge with its own column-type inference.

Reproduce with:

cargo bench --features mlt --bench mlt -- mvt_to_mlt_transcode

Real-data tiles (z4/z7/z13) transcode ~20-23% faster because the native reader skips the intermediate GeoJSON allocation and hand-rolled type inference. The trivial z0 world-overview tile regresses ~7% — its near-empty payload is dominated by the reader's fixed setup cost, so there is nothing to amortise. All deltas are statistically significant (p < 0.05). Both sides run mlt-core 0.11.0, so this isolates the reader change rather than the version bump. Absolute timings are machine-specific (measured on Apple Silicon, --release); the percentage deltas are the portable signal.

In-process benches at a glance

The crate ships ten criterion benches that exercise pure-function hot paths across every feature without an HTTP harness. All are reproducible from a clean checkout:

cargo bench --bench cache                       # tile cache lookups
cargo bench --bench cog --features stac         # COG path classification (vsicurl/vsis3)
cargo bench --bench duckdb --features duckdb    # tile→bbox + SQL template substitution
cargo bench --bench frontend                    # MIME guessing + cache-control rule
cargo bench --bench geoparquet --features geoparquet # tile→bbox (plain + buffered)
cargo bench --bench mlt --features mlt          # MLT parse / decode / transcode
cargo bench --bench postgres --features postgres # geometry-type + JSON Schema mapping
cargo bench --bench raster --features raster    # raster encode / mosaic / band math
cargo bench --bench stac --features stac        # bbox merging + URL classification
cargo bench --bench styles                      # style.json URL rewriting

Why these ten: they cover the per-request work that runs inside the Tokio worker — between when the router dispatches and when bytes are written back to the socket. Network, Postgres round-trips, and disk reads are excluded by design (those are measured in the benchmarks/ HTTP harness). Every cargo feature flag now has at least one corresponding bench so contributors can verify their changes haven't regressed any feature's hot path.