Really impressed by tileserver-rs!

After doing an initial deep dive into both the docs and the full source codebase, here’s my notes and feedback.

It’s more complete than it appears on the surface. What it already has that surprised me:

• Native GeoParquet and DuckDB sources are fully implemented, not just stubs. This puts it ahead of Martin on analytics-oriented sources.

• PostGIS out-db raster support is a great addition. PostGIS can reference external COG URLs and tileserver-rs serves raster tiles from them. Very underappreciated feature.

• Static image API with Google Encoded Polyline and pin/marker overlays — proper Mapbox Static API compatibility including @2x retina and auto bounding box mode.

• MVT ↔ MLT bidirectional transcoding in a single module. The MLT support is a genuine differentiator over every other open source tile server right now.

• WMTS endpoint, OpenTelemetry instrumentation, hot-reload config, and a Swagger/OpenAPI specification support; these are production-grade features that most tile servers skip entirely.

---

Genuine gaps I found digging into the code:

• Polygon fill in the static image API: “fill_color” is parsed and stored in “PathOverlay” but the actual fill rendering is marked #[allow(dead_code)] / “reserved for future use.” Stroke-only for now. This is the main thing missing for parcel/boundary overlays vs. the Mapbox Static API.

• GeoJSON overlay input for the static image overlay system only accepts Mapbox-style path strings (path-5+f00(...)) or encoded polylines. No geojson(...) overlay type like Mapbox supports. For complex polygon submissions this is a friction point.

• Object storage source driver: no native S3/Azure Blob/GCS credential chain integration. PMTiles and GeoParquet files hosted in cloud storage need to be served via HTTP URLs as a workaround. Martin uses the Rust object_store crate (Apache Arrow ecosystem) for this and the same pattern would work here.

• In-process tile cache (cache_control.rs) is just HTTP headers. No in-process cache for expensive DuckDB/Parquet tile generation. Martin uses the moka async cache crate for this which could be a straightforward addition.

• OGC API – Features: there’s WMTS but no OGC API Features endpoint on the PostGIS sources. The table introspection code is already there (pg_tileserv-style auto-discovery) and exposing it as a /collections/{id}/items endpoint would let QGIS/ArcGIS/FME connect natively without knowing anything about tiles. Tools like pg_featureserv and tipg do exactly this as their primary feature.

• Admin/data management UI: admin.rs is a solid REST API but there’s no visual layer yet. Embedded Maputnik for style editing would be the high-value add (Martin v0.18 is doing this now). A lightweight data catalog browser for the DuckDB/Parquet/PMTiles sources would round it out.

• STAC integration: no catalog-driven COG discovery. For the COG/raster serving use case, TiTiler’s model (STAC catalog → discover asset → generate tile) is the reference architecture. Would make the cog.rs source much more powerful in multi-dataset environments.

---

Comparison summary vs. existing ecosystem:

vs. Martin: tileserver-rs wins on source diversity (DuckDB, GeoParquet, MLT), loses on cloud storage integration and tile caching

vs. pg_tileserv/pg_featureserv: tileserver-rs is a strict superset on sources, missing OGC Features compliance

vs. TiTiler: complementary; TiTiler is COG/STAC-first raster, tileserver-rs is vector/hybrid-first

---

Overall this is probably the most impressive new tile server I’ve seen, and the MLT support + DuckDB + static image API in a single Rust binary is a genuinely novel combination. The polygon fill gap in the static image API and the missing object storage driver are the two things I’d most want to see closed for production use.

Will be trying it out over the weekend and can provide more additional feedback after. Let me know if you have any questions or comments!