swiftmap vs folium, deck.gl, kepler.gl and datashader
Five libraries that all put data on a map, separated by what they optimise for. folium and ipyleaflet have Leaflet's ergonomics but hit a ceiling in the tens of thousands of features. deck.gl scales, with its own layer and view-state model and a thin Python layer over it. kepler.gl is an application you configure rather than a library you call. datashader goes further than any of them on raw volume by rasterising server-side — which is also why what arrives in the browser is a picture rather than features you can click.
swiftmap keeps the Leaflet model and puts WebGL pipelines under it, so the map you
write in a few add_* calls stays interactive at a million features.
The table below includes the row where that trade-off loses.
| folium / ipyleaflet | deck.gl (pydeck) | kepler.gl | datashader | swiftmap | |
|---|---|---|---|---|---|
| Points before it stops being usable | tens of thousands | millions | millions | hundreds of millions | millions — drag the map above |
| Mental model | Leaflet | its own layer/view stack | a configurable app | a rasterising pipeline | Leaflet |
| What reaches the browser | JSON per feature | typed arrays | JSON or Arrow | a rendered image | binary float64 buffers |
| Per-feature click and hover | yes | yes | yes | no — pixels, not features | yes, at a million |
| Layer control | flat list | build it yourself | flat list in its own UI | you compose it | hierarchy from your columns |
| Cost of a layer toggle | re-render | re-render | re-render | re-raster | a ~100-byte patch, at any scale |
| Python ↔ map sync | one way | one way | one way | one way | bidirectional (viewport, clicks, draws, time) |
| Time playback | plugin, DOM-based | manual | built in | manual | built in, filtered on the GPU |
| Offline / air-gapped | CDN at view time | CDN at view time | CDN at view time | renders server-side | everything inside the wheel |
| Static share | one HTML file | one HTML file | one HTML file | an image, or a Panel app | one HTML file, sidebar and time included |
| 3D — extrusions, terrain | no | yes | yes | no | not yet |
Measured, not claimed: the hero on the home page draws 1,000,000 points in roughly 800 ms from mount to first paint and stays interactive while you drag it — the readout under it is live, not a graphic. The other columns describe design centres; nothing here times them. Run your own comparison — the code behind every map on this site is printed underneath it.
Where it misses, honestly
A comparison table that wins every row is a pitch, not an analysis. These are the places another library is the better answer today. They are known, they are on the list, and this section shrinks as they land — it has already lost density, raster imagery, WMS, offline, marker clustering and line direction since it was first written.
3D
No extrusions, no terrain, no camera pitch. deck.gl owns this, and a Leaflet-shaped library will always be a step behind it here.
Vector tiles
read_mvt brings a vector-tile dataset in as an ordinary table
— the bridge, not a renderer. There is still no vector-tile basemap, so a
style-driven basemap has to come in another way.
Earth-observation catalogues
add_imagery warps a raster you already have. STAC, COG and Earth
Engine integration is leafmap's territory, not this library's.
First paint at the top end
Millions of points drag smoothly once they are there. Getting them there still costs more than it should on the very largest maps.
Try it against your own data
The fastest way to settle a comparison is to run it. Every map on the home page is live and the code that built it is printed underneath — six lines, most of the time.
pip install swiftmap