tileserver-rs is designed for high-performance tile serving. This page documents benchmark results for PMTiles, MBTiles, PostgreSQL, and Cloud Optimized GeoTIFF (COG) sources.

Test Environment

• Hardware: Apple Silicon (M-series) MacBook
• Runtime: All servers running in Docker containers (ARM64 native)
• Test Tool: autocannon (Node.js HTTP benchmarking)
• Configuration: 100 concurrent connections, 10 seconds per endpoint

Test Data

Summary Results

Captured 2026-04-25 against tileserver-rs:latest on main (post-v2.26.4), Apple M2 / 16 GB, Docker Desktop ARM64 native, 100 concurrent connections, 10 seconds per zoom.

PMTiles consistently sustains 1,200-1,600 req/s in the city-zoom band (z10-z14) at ~89 MB/s. MBTiles peaks at z12-z13 (1,000+ req/s) but tails off at z14 due to SQLite scan cost on the larger Zurich tileset.

Detailed Results by Zoom Level

PMTiles (Florence, Italy)

MBTiles (Zurich, Switzerland)

Analysis

Key Insights

• Throughput is steady at ~85-95 MB/s across zoom levels for both formats
• PMTiles is consistently faster (1,355 vs 759 req/s avg) — single seek per tile vs SQLite row lookup
• z14 is where the formats diverge sharply: PMTiles holds 1,496 req/s, MBTiles drops to 239 due to SQLite scan over the larger Zurich tileset

PMTiles Performance

• Best at city zoom (z11-z14): consistently 1,400-1,600 req/s with 60-80ms latency
• Memory-mapped file access provides predictable performance — cache_hit micro-bench at 185 ns
• z15 dips to 796 req/s because Florence's z15 tiles are denser (more vector features per tile)

MBTiles Performance

• Best at city zoom (z12-z13): 1,000+ req/s
• z14 drop is real: 239 req/s @ 421ms — Zurich z14 tiles are large (~95 KB each), exposing SQLite scan cost
• Good for local development and smaller datasets where peak throughput isn't critical

Format Comparison

Running Benchmarks

To reproduce these benchmarks with fair Docker-to-Docker comparison:

# Build tileserver-rs Docker image for your platform
docker build -t tileserver-rs:local .

# Update benchmarks/docker-compose.yml to use local image
# Then start all servers
docker compose -f benchmarks/docker-compose.yml up -d

# Run benchmarks
cd benchmarks
pnpm install
node run-benchmarks.js --duration 10 --connections 100

Benchmark Options

# Test only PMTiles
node run-benchmarks.js --format pmtiles

# Test only MBTiles
node run-benchmarks.js --format mbtiles

# Test PostgreSQL table sources
node run-benchmarks.js --format postgres

# Test PostgreSQL function sources
node run-benchmarks.js --format postgres_function

# Test COG/raster sources
node run-benchmarks.js --format cog --connections 10

# Test specific server
node run-benchmarks.js --server tileserver-rs

# Longer test with more connections
node run-benchmarks.js --duration 30 --connections 200

# Generate markdown report
node run-benchmarks.js --markdown

Server Comparison

We benchmarked tileserver-rs against martin and tileserver-gl using the same test data. All servers ran in Docker containers on ARM64 for a fair apples-to-apples comparison.

PMTiles Performance (Florence, Italy)

tileserver-rs is ~15% faster than tileserver-gl and ~21× faster than martin for PMTiles serving.

MBTiles Performance (Zurich, Switzerland)

All three servers are within ~7% on req/sec for MBTiles. tileserver-rs leads on raw throughput; martin leads on latency due to its in-memory tile cache (~155ms vs 183ms).

PostgreSQL Performance (Zurich Points)

Captured 2026-04-25 against the same benchmarks/docker-compose stack with PostGIS 3.6.2 + PostgreSQL 18 (Docker postgis/postgis:18-3.6 ARM64). 50,000 row benchmark_points table, 100 connections, 10 seconds per zoom.

tileserver-rs edges martin by ~4% on req/sec and ~7% on latency. Both are PostGIS-bound: the database query + ST_AsMVT dominate response time, not the tile server overhead.

PostgreSQL by Zoom Level (tileserver-rs vs martin)

PostgreSQL Optimizations

tileserver-rs includes several PostgreSQL performance optimizations:

• Connection pool pre-warming - All connections established at startup
• Prepared statement caching - Tile queries pre-prepared on all connections
• ST_TileEnvelope margin - PostGIS 3.1+ margin parameter for better tile edge clipping
• SRID-aware envelope transformation - Transform tile envelope to table SRID instead of every geometry
• Moka-based tile cache - LRU cache with configurable size and TTL

Feature Comparison

tileserver-rs provides the best balance: fastest PMTiles performance (~6% faster than tileserver-gl, 25× faster than martin), now leading on PostgreSQL too (3,571 vs martin's 3,439), native MapLibre rendering for raster tiles, static image generation — all in a single binary.

COG/Raster Performance

tileserver-rs supports Cloud Optimized GeoTIFF (COG) serving with on-the-fly reprojection and PNG encoding via GDAL.

Test Configuration

• COG File: 4096x4096 RGB image in Web Mercator (EPSG:3857)
• Connections: 10 concurrent (COG processing is CPU-intensive)
• Output: 256x256 PNG tiles

COG Benchmark Results (tileserver-rs)

Key Observations

• Latency scales with tile complexity - Lower zoom levels read more data from the COG
• Higher zoom = faster - z3+ tiles achieve 38+ req/s with sub-300ms latency
• CPU-bound - COG processing (GDAL read + PNG encode) limits throughput
• LZW compression - The benchmark COG uses LZW compression; uncompressed COGs are faster

Running COG Benchmarks

# Test COG performance only
node run-benchmarks.js --format cog --connections 10

# Compare with TiTiler (Python COG server)
docker compose -f benchmarks/docker-compose.yml up -d titiler tileserver-rs
node run-benchmarks.js --format cog --server tileserver-rs
node run-benchmarks.js --format cog --server titiler

TiTiler Comparison

TiTiler is a Python-based COG tile server by Development Seed, built on rio-tiler/GDAL and FastAPI. We benchmarked both servers with the same COG file (4096×4096 RGB, EPSG:3857) at 10 concurrent connections.

COG Performance by Zoom Level

Why tileserver-rs Still Wins Overall

TiTiler only serves COG/raster data. tileserver-rs is a unified tile server that handles everything in a single binary:

Run docker compose -f benchmarks/docker-compose.yml up -d to start both servers for 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.

End-to-end COG tile serving — live comparison

Measured on the same machine (Apple M2, 12 cores, Docker Desktop ARM64) with the benchmark harness in benchmarks/run-benchmarks.js. Both servers run in Docker containers, serve identical local COG fixtures, and receive identical autocannon load (50 concurrent connections, 10-second measurement, 30-second warmup).

tileserver-rs serves COG tiles ~30× more throughput at ~21× lower latency than titiler on the same hardware.

Per-zoom detail:

The dominant contributor to the speedup is overview pyramid selection (commit #9): GDAL is opened with OVERVIEW_LEVEL=N so the warp reads from a pre-computed overview instead of the full-resolution raster. Secondary contributors: Moka-cached Dataset handles (commit #2), parallel mosaic compositing via futures::join_all (commit #3), and the RasterImage ndarray pipeline that keeps pixel values in float form through the mosaic layer (commits #1, #4).

Reproduce locally:

docker build -t tileserver-rs:latest .
docker compose -f benchmarks/docker-compose.yml --profile all up -d
node benchmarks/run-benchmarks.js --type cog --duration 10 --connections 50 --markdown

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.

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).

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.

• 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).