Fastest Geospatial Desktop Stack

Benchmarks across the three layers of a geospatial desktop app — rendering, shell, and data path — measured on an Apple M2 Max, 120 Hz. Source: geo-desktop-bench.

Live demos

The desktop capstone (DuckDB-on-Rust in Tauri) is native — see the repo. The web capstone above is the in-browser equivalent (DuckDB-WASM).

Rendering — deck.gl vs MapLibre vs raw WebGL2

Same synthetic point cloud, same deterministic camera path, frame-time percentiles (8.33 ms = a 120 Hz frame).

• At ≤1M points the engine doesn't matter — all three pin the refresh cap.
• The wall shows at 3M+: raw WebGL2 stays smooth to 10M; deck.gl's abstraction costs ~2.4× throughput at the extreme.
• ¹ MapLibre's GeoJSON path doesn't fail on FPS — it fails on load: 1M points = 9.5 s to first frame (main-thread tiling). Past ~1M, use vector tiles (the PMTiles demo), not a GeoJSON source.
• Time-to-first-render: deck.gl ~33 ms flat (GPU projection) beats raw WebGL2's CPU loop (381 ms @10M).

Native render — maplibre-rs (wgpu → Metal), no webview

Every engine above draws inside the webview's WebGL2 context. maplibre-rs is the other corner of the design space: a Rust vector-tile renderer that goes straight to Metal through wgpu — no webview, so the WKWebView WebGPU gate that limits a Tauri app simply doesn't apply. Same firenze.pmtiles basemap as the PMTiles demo, driven by a deterministic camera path (rotate + tilt over the resident tile), rendered offscreen on the M2 Max.

• Native draws the basemap in ~1.7 ms with zero jank, uncapped — ~5× under the 8.33 ms frame a webview engine can never beat. Both look smooth at 120 Hz; the difference is GPU headroom, not wall-clock fps.
• This is the answer to the shell section's asterisk below: render in native Rust and the WKWebView WebGPU gate stops mattering — no need for Chromium to get GPU headroom, so Tauri keeps its 86× size win and its rendering ceiling.
• ⁴ The in-webview MapLibre basemap pins the 120 Hz refresh cap (rAF is vsync-locked), so its frame floor is 8.33 ms — it wasn't separately percentile-profiled here; the honest comparison is headroom under that floor, not who's faster on the clock.
• Caveats: render-stage frame time with the tile resident (uploaded once, then the camera moves) — not a streamed multi-tile fly-over. maplibre-rs is experimental — fill + line only, no labels (fine here, the Firenze style is label-free) — and has no PMTiles reader, so tiles were bridged through a local martin server. Basemap-vs-basemap; not comparable to the point-cloud table above.

Desktop shell — Tauri vs Electron

• ² Tauri RSS undercounts on macOS — WKWebView's WebContent is a system-hosted process outside the app tree, so the real gap is smaller (but Electron is clearly heavier).
• ³ Different zero-points (Tauri = process entry; Electron = post-Chromium-boot), so the startup comparison isn't apples-to-apples — not a real win for either.
• Embedding DuckDB takes the Tauri binary 3.2 MB → ~82 MB stripped — still far under Electron's 275 MB shell before any app code.
• Electron's only clear edges: per-call IPC and full WebGPU (WKWebView gates it).

Data path — DuckDB-spatial & PMTiles

• For an axis-aligned box a scalar column range beats the spatial predicate ~25× — spatial functions earn their cost on complex geometry, not rectangles.
• DuckDB is embedded (Rust side of Tauri) — no network, no serialization. PMTiles is a single file, range-read off disk/CDN — no tile server.

Method & caveats

• Rendering: deterministic web-mercator camera path, warm-up discarded, frame-time percentiles (rAF is refresh-capped, so the tail — p95/p99/jank — is the signal, not mean FPS). Run in Firefox; reps=1.
• Shell size: tauri build (release, stripped, LTO) vs electron-builder --dir (unsigned). RSS sampled across the process tree over 5 launches.
• All numbers are one machine (M2 Max), point-in-time, and reproducible from the repo — directional, not authoritative leaderboards.