A 20M × 20M canvas with PostGIS

Pixel Wall is a multiplayer canvas with a 20,000,000 × 20,000,000 coordinate space. You can't ship that as one image, and you can't query it with a naive WHERE x BETWEEN … AND y BETWEEN … once thousands of people are painting at once. The interesting problems are all about the viewport.

The viewport is the query

A client only ever sees a rectangle. So the server's job reduces to: given a bounding box, return the pixels inside it, fast — no matter where in the 400-trillion-cell space that box happens to be.

-- a GiST index over pixel geometry makes the viewport a range scan
SELECT x, y, color
FROM pixels
WHERE geom && ST_MakeEnvelope($1, $2, $3, $4, 0);

PostGIS with a GiST index turns that into an indexed spatial lookup instead of a full scan. The && operator does the heavy lifting.

Rendering without a library

No canvas library survives this — they assume a small, finite surface. The renderer is hand-written against the raw HTML5 Canvas API: a tile cache keyed by viewport zone, dirty-rect updates over Socket.IO, and a coordinate transform that keeps float precision sane out at the edges.

Charging for space

Zones are priced dynamically and settled through Stripe Payment Intents with webhook verification — which means the spatial model isn't just a rendering concern, it's the billing primitive too. That coupling is the part I'd design the same way again.