Notes
A Decision Tree for Cloud-Native Geospatial Architecture
A practical way to choose formats, databases, compute engines, and serving tools by the problem each layer needs to solve.
The modern geospatial stack has become surprisingly large. GeoJSON, GeoParquet, COG, MVT, PMTiles, PostGIS, DuckDB, Apache Iceberg, Martin, TiTiler, Sedona, STAC — each solves a different problem, but it is not always obvious where one ends and another begins.
Instead of asking:
Which geospatial technology should I use?
A more useful question is:
What problem am I trying to solve at each layer of the system?
This article presents a practical decision tree for choosing technologies for cloud-native geospatial systems.
The Decision Tree
Choosing a Geospatial Delivery Architecture
Format and serving decisions describe how an individual dataset moves through the system. A second decision tree becomes useful when the dataset grows beyond a manageable collection of files.
Scaling the Data Layer
The important part of these decision trees is that these technologies are not necessarily competitors. They often belong to completely different layers.
1. Start With Raster vs. Vector
The first distinction is fundamental. Raster data represents space as pixels:
- Satellite imagery
- Elevation
- Temperature
- Land cover
- Wildfire severity
Vector data represents geographic objects:
- Buildings
- Roads
- Administrative boundaries
- Wildfire perimeters
- Points of interest
These two kinds of data lead us toward different cloud-native formats: GeoTIFF to COG for raster data, and GeoJSON to GeoParquet for vector data. But COG and GeoParquet are not simply newer replacements. They solve a different problem: efficient access to large datasets in object storage.
2. Do You Need Analytical Data or a Web Map?
This is probably the most important question in the decision tree. Consider a vector dataset containing 100 million buildings.
If we want to analyze it, we may want to run:
Or perhaps:
GeoParquet is a good fit for this type of workload. But the browser does not need the entire analytical dataset. It needs something like:
containing only the features required to render the current map. That is the job of MVT — Mapbox Vector Tiles.
This gives us an important separation:
GeoParquet is optimized for querying data, while MVT is optimized for delivering maps. Trying to use one format for both responsibilities often creates unnecessary complexity.
3. Static or Dynamic?
Once we decide to serve vector tiles, another question appears:
How often does the dataset change?
For relatively static datasets, pre-generating tiles is often the simplest architecture. GeoJSON or GeoParquet can be processed with tippecanoe, stored as PMTiles on S3, and delivered through a CDN. Because no database or tile server is required for every map request, this architecture can be extremely simple and inexpensive.
But suppose the data changes frequently or users need dynamic filtering. For example:
Now pre-generated tiles become less attractive. A dynamic architecture may make more sense, with Martin generating MVT from PostGIS when a tile is requested.
4. What if Dynamic Tiles Become Too Expensive?
A common mistake is to solve slow tile generation by simply giving the server more resources. Before doing that, ask:
Does this zoom level actually need all of these features?
At zoom level 6, rendering every individual building in a city usually provides little value. Instead:
- z0–8: aggregated or heavily simplified
- z9–12: selected features with simplified geometry
- z13+: detailed features
With Martin and PostGIS, this logic can live in database views, materialized views, or tile functions.
The important optimization principle is:
Do not make tile generation faster until you have minimized the amount of data that needs to reach tile generation.
5. Raster Has a Similar Story
Traditional raster serving typically routed a GeoTIFF through a GIS server to produce WMS or raster tiles. Cloud Optimized GeoTIFF changes this architecture by organizing raster data so that clients can retrieve only the byte ranges they need.
A 10 GB raster does not necessarily require downloading 10 GB. The tile server can read only the blocks required for the requested geographic region and resolution.
This is one of the fundamental ideas behind cloud-native geospatial architecture:
Move computation to the data and avoid moving data unnecessarily.
6. What Happens When There Are Millions of Files?
COG and GeoParquet solve the problem of efficiently accessing individual files. But eventually another problem appears. Imagine:
Or imagine millions of satellite scenes stored as COGs. Now the question becomes:
Which files should the query engine open?
This is where table formats such as Apache Iceberg become important.
Iceberg does not replace Parquet or COG. It manages datasets composed of many files and adds capabilities such as:
- snapshots
- schema evolution
- partitioning
- file pruning
- transactional updates
Spatial extensions and platforms such as Havasu and Wherobots build geospatial capabilities on top of this model.
7. DuckDB or Distributed Computing?
Once the data is in Parquet or GeoParquet, another decision is how to query it. For datasets that fit comfortably on a single machine, DuckDB can query GeoParquet directly from S3 without first loading it into a traditional database. For much larger workloads, distributed processing with Iceberg, Spark, and Sedona becomes useful. Platforms such as Wherobots build on this model to provide large-scale spatial computation.
The decision is not:
DuckDB or Spark — which is better?
It is:
Does this workload actually require distributed computation?
For many workloads, the answer is no.
8. STAC Solves Yet Another Problem
STAC is easy to confuse with the technologies above, but STAC is primarily about discovery and cataloging.
A STAC Item might describe the datetime, bounding box, geometry, platform, cloud cover, and assets for a satellite observation. The actual assets may be COGs. STAC tells us what data exists and where it is; COG or GeoParquet describes its physical representation. Iceberg manages a large collection as a table, DuckDB or Sedona queries it, and tiles deliver the result to a map. These are different responsibilities.
A Better Mental Model: Layers, Not Tools
Instead of memorizing dozens of technologies, I find it more useful to think in layers.
Once technologies are placed into these layers, many apparently difficult technology choices become much simpler. For example, asking:
Should we use PMTiles or GeoParquet?
is often the wrong question because they solve different problems.
A system could legitimately use GeoParquet for analysis and then pass the result through a tile pipeline to create PMTiles for a web map. Similarly, COG and Iceberg are not competing raster formats. One describes how raster data can be efficiently accessed, while the other helps manage datasets containing potentially millions of files.
The Core Principle
Cloud-native geospatial architecture is less about choosing a single technology and more about minimizing unnecessary data movement at every layer. Can the system avoid reading a file, row group, or column? Can it avoid processing a geometry, placing a feature in a tile, or sending data to the browser?
COG, Parquet, Iceberg, spatial indexes, vector tiles, PMTiles, and CDN caching may look like unrelated technologies. But they share a surprisingly similar idea:
Read, process, and transfer only the data that is actually needed.
That principle is perhaps the most useful starting point for designing a cloud-native geospatial system.