How to Add Heatmaps to Your App (Copy-Paste Prompts Included)

A marker map shows individual pins at specific coordinates — each pin is a distinct data point. A heatmap shows the density or intensity of many overlapping data points as a colour gradient — individual points are indistinguishable, but you can see where activity is concentrated. Heatmaps are better for large datasets (thousands of events) where individual markers would overlap unreadably. Marker maps are better for browsing specific items.

Add a GeoJSON source to your Mapbox map with an id like 'heatmap-source'. Add a layer with type: 'heatmap' that reads from that source. Configure the paint properties: heatmap-weight references a 'weight' property on each feature; heatmap-color is a step or interpolate expression mapping 0–1 to your colour ramp; heatmap-radius controls the blur radius in pixels. The GeoJSON source data must come from a server-side aggregation endpoint — never a raw table query.

No. HeatmapTileProvider in the Google Maps Flutter SDK is not exposed through FlutterFlow's visual widget panel. You need a Custom Widget code block with Dart code. It is achievable but requires Flutter development knowledge. For a heatmap feature without native mobile requirements, V0 + Next.js + Mapbox GL JS is significantly simpler.

Create a Supabase Edge Function that accepts the map viewport bounds and zoom level as parameters. Inside the function, call a PostgreSQL RPC that uses ST_SnapToGrid (groups raw lat/lng coordinates to a grid cell and sums their weights) or the H3 hexagonal indexing library. Return the aggregated results as a GeoJSON FeatureCollection where each feature has a weight property. The browser receives compact GeoJSON with a few hundred cells, not thousands of raw rows.

H3 is Uber's open-source library that divides the world into a hierarchical grid of hexagons at multiple resolutions. Resolution 4 has hexagons ~86km across; resolution 10 has hexagons ~0.15km across. For heatmaps, H3 is valuable because you can adapt the hexagon size to the zoom level — zoomed out shows province-scale density, zoomed in shows block-scale density. PostGIS ST_SnapToGrid is simpler but less elegant at multiple zoom levels. For a basic analytics heatmap, ST_SnapToGrid is sufficient. H3 is worth the extra complexity if you need smooth zoom transitions.

With server-side aggregation: essentially unlimited — the database aggregates millions of events into a few hundred GeoJSON cells before sending anything to the browser. Without aggregation: browser performance degrades noticeably above 5,000–10,000 raw points and the tab freezes or crashes above 50,000. The architecture is the bottleneck, not the total row count.

Yes — pass filter parameters to the aggregation API. The heatmap_aggregated() RPC accepts date_from, date_to, and event_type as optional parameters. Each filter control change re-calls the API with updated params and replaces the Mapbox GeoJSON source data. Debounce slider-based filters by 300ms to avoid firing API calls on every pixel of slider movement.

Only if you build it incorrectly. The safe architecture: enable Supabase RLS on heatmap_events with a policy that denies direct SELECT from public (USING false). All reads go through a Supabase Edge Function that calls the aggregation RPC with the service role key and returns only GeoJSON with aggregated weights — no row IDs, no timestamps, no user identifiers. Individual events are never reconstructible from the aggregated output.