ST_AsGeoJSON looks efficient in queries. It’s a disaster in production APIs. You’re forcing a database optimized for filtering and joining to become a text serialization engine.
Here’s the cost: converting a geometry to JSON text inside Postgres is CPU-intensive string concatenation. A coordinate that takes 16 bytes as WKB (two 8-byte doubles) becomes 25–30 bytes in JSON ([ -122.456789, 47.123456 ]). Multiply by millions of coordinates, and you’ve 2-5x bloated the payload. Network bandwidth explodes.
Worse: the database can’t parallelize. String building is sequential. Query parallelism stalls. The database becomes a bottleneck for feature serialization instead of doing what it does best—filtering and joining.
The correct architecture: the database filters and returns WKB (binary). A fast, stateless application server (Node, Python, Go) handles conversion. These layers are designed for it. A Python client decoding WKB is 10x faster than Postgres generating JSON text.
For web maps, skip the middle step entirely. Use ST_AsMVT to generate vector tiles directly from SQL. Binary on the wire. No JSON. No bloat.
ST_AsGeoJSON has one use: ad-hoc debugging. Never production APIs.
The rule: Keep the database binary. Text is for browsers and logs, not backend-to-backend communication. Use WKB or MVT. Let the application layer handle serialization.
Whenever you’re ready, here are 4 ways I can help you grow in GIS & spatial data:
Spatial Lab – My private community where GIS professionals, data engineers, and analysts connect, swap workflows, and build repeatable systems together.
Modern GIS Accelerator – A guided program to help you break out of legacy GIS habits and learn modern, scalable workflows.
Career Compass – A career-focused program designed to help GIS pros navigate the job market, sharpen their pitch, and find roles beyond traditional GIS paths.
Sponsorship: Interested in sponsoring this newsletter (or other content)? Learn more here and fill out the form to get in touch!
