Performance bottleneck when adding 8000+ PMTiles layers dynamically

[anatolysukhanov]

Hi MapLibre team 👋,

We’re working on a bathymetric map application that loads around 8000 individual .pmtiles raster files (each covering ~1° bounding boxes, zoomed 8–14). The PMTiles are stored on S3 and accessed via the pmtiles protocol using maplibregl.addProtocol().

Our current workflow:

• A tilesets.json file lists all PMTiles with url, bounds, minzoom, and maxzoom.
• On map load, we loop over the list and call map.addSource() and map.addLayer() for each.
• We use Vue to control visibility, opacity, and layer order.

Here’s an example entry:

{
  "url": "https://bmapi.bathymaps.com.au/layers/Z1_very_low/region_1008_combined_shaded_relief_Deep_very_low.pmtiles",
  "bounds": [135.9896909, -36.5179775, 136.3769589, -35.9886269],
  "minzoom": 9,
  "maxzoom": 10
}

🚨 Problem

Once we pass a few hundred layers, map performance tanks. Adding all sources/layers takes minutes, and interaction becomes sluggish—even though most tiles aren’t immediately visible.

We assume the bottleneck is not tile loading, but the cumulative cost of addSource + addLayer setup on the JS side.

🧩 What we’re exploring

• Using Martin server to create composite raster sources.
• Programmatic paging/loading of sources within viewport.
• Avoiding addLayer() until the layer is about to be shown.

🙏 Questions

1. Is there a MapLibre-native way to efficiently manage thousands of raster layers?
2. Can we dynamically load sources/layers only when they become visible (lazy init)?
3. Are there plans to support composite PMTiles sources similar to vector TileJSON?

Thanks in advance — and thank you for maintaining such a powerful open-source mapping library!

[HarelM]

I'm not sure I fully understand the setup, but you should be able to use addProtocol to load only the relevant data from the relevant PMTiles and avoid adding all the layers and sources. But I might be wrong...

[anatolysukhanov]

Thanks for the quick response. Let me clarify:

• We’re already using addProtocol("pmtiles", ...), and it works well for reading .pmtiles files.
• However, each .pmtiles file still requires a corresponding map.addSource() and map.addLayer() for it to show on the map.
• The issue isn’t tile fetching — it’s the fact that creating 8000+ sources and layers upfront freezes the browser, even if most of them are outside the current view.

So even though PMTiles itself is efficient, MapLibre slows down due to the volume of sources/layers.

What we’re hoping to find is a way to:

• Use a composite source or virtual tile index that routes tile requests to the correct PMTiles file without needing to create thousands of sources.
• Or: Lazy-load sources/layers only when their bounds intersect the current viewport, and remove/unload them when not in view.

[HarelM]

You can use addProtocol to create a composite source...

[anatolysukhanov]

Thanks Harel - this sounds very promising.

So just to confirm: you're suggesting that we could define a single composite pmtiles:// source, and in the custom protocol handler (registered via addProtocol), we inspect the z/x/y and dynamically route the tile request to the appropriate .pmtiles file?

That would solve our problem beautifully. We were originally thinking we needed to addSource for each file, but this approach would let us completely skip that and keep just one source/layer on the map.

I'll try prototyping this. Would love any pointers if there’s a recommended pattern or example of a composite source like this in the wild.

[HarelM]

The following is still not in production and is used to load offline files sliced by zoom 7 areas, but it is practically the same idea:
https://github.com/IsraelHikingMap/Site/blob/2030fa3290df62ac7c41e22f98d3b5e10abe5a34/IsraelHiking.Web/src/application/services/database.service.ts#L97

[neodescis]

I take it you also have thousands of pmtiles archives? Why the need for so many? Can you combine the data before it makes its way to MapLibre?

As for lazy-loading sources/layers: are you setting bounds on the sources? It should help, though thousands of sources is still likely to be a problem.

[anatolysukhanov]

Yes, we currently have thousands of .pmtiles archives. The reason is:

1. Each .pmtiles file represents a small survey region (often <1°), across multiple styles (Magma, PaleoMaps, Deep, etc.).

2. Combining them ahead of time isn’t always practical due to:

   Data ownership separation (e.g. from different surveys or contributors).
   Ongoing uploads — we need to dynamically ingest new files dropped into S3.

We’ve considered combining them, but the size, boundaries, and update frequency make it hard to merge reliably.

Regarding bounds on sources: yes, we’ve tried setting bounds, minzoom, and maxzoom per source. It helps tile loading, but doesn’t reduce the DOM/JS load caused by calling addSource and addLayer 8000+ times.