Cloud-native geospatial architecture refers to the design and implementation of geographic data systems that embrace cloud computing primitives — object storage, managed compute, serverless functions, and cloud-optimised data formats — rather than lifting traditional on-premise GIS infrastructure into the cloud.
The distinction matters: “GIS in the cloud” might mean running ArcGIS Server on an EC2 instance. “Cloud-native geospatial” means redesigning the data pipeline from scratch around the capabilities and constraints of distributed cloud infrastructure.
The Shift to Object Storage
Traditional geospatial workflows centred on file servers or PostGIS databases. Cloud-native workflows treat object storage (S3, GCS, Azure Blob) as the primary data lake — infinitely scalable, accessed via HTTP, and decoupled from compute.
This enables three patterns that are awkward or impossible with traditional infrastructure:
HTTP Range Requests — cloud-optimised formats like Cloud-Optimised GeoTIFF (COG) and GeoParquet support byte-range reads. A client can fetch only the spatial tile it needs from a multi-gigabyte file stored in S3, without downloading the whole file. This eliminates tile servers for many raster use cases.
Serverless analytics — DuckDB, Athena, and BigQuery can query Parquet files directly on S3 using SQL without staging data into a database. A query over 10 billion GPS points executes in seconds against files that never move.
Separation of storage and compute — storage scales to exabytes cheaply; compute spins up on demand. Traditional PostGIS on a single server conflates the two, forcing you to provision for peak load.
Cloud-Optimised Formats
The cloud-native geospatial stack has converged on a set of formats designed for HTTP-range-request access:
GeoParquet — columnar geospatial data (points, lines, polygons) in Parquet format with geometry encoded as WKB. Queryable with DuckDB, Arrow, GeoPandas, and Spark. The Overture Maps Foundation distributes its global dataset as GeoParquet on S3.
Cloud-Optimised GeoTIFF (COG) — raster imagery with internal tiling and overviews, structured so that any zoom level or spatial extent can be read with one or two HTTP requests.
PMTiles — a single-file format for vector and raster tiles, stored in object storage and served directly without a tile server. An S3 bucket and a CloudFront CDN replaces an entire Tegola or Martin tile server deployment.
FlatGeobuf — streamable vector format with a spatial index, enabling spatial-range queries via HTTP without downloading the complete file.
Serverless Compute Patterns
ETL pipelines — AWS Lambda, GCP Cloud Run, or Azure Functions ingest new data, transform it to cloud-optimised formats, and write to S3. Triggered by S3 events, no persistent infrastructure required.
On-demand tiling — Lambda functions receive a tile request (z/x/y), query a PostGIS or DuckDB source, and return vector tile bytes. No tile cache needed for low-traffic endpoints.
Batch geospatial processing — AWS Batch or GCP Cloud Run Jobs run containerised Python scripts against large datasets (OSM planet, Sentinel-2 archives) using managed parallelism.
Infrastructure as Code
Cloud-native geospatial systems are defined as code using Terraform, CDK, or Pulumi. The complete infrastructure — S3 buckets, Lambda functions, API Gateway routes, IAM policies, CloudFront distributions — lives in a Git repository and can be reproduced in a new account in minutes.
This is a significant departure from traditional GIS servers, where environment configuration was manual and server state was opaque.
When Cloud-Native Isn’t the Answer
Cloud-native geospatial architecture excels at large-scale analytics, ML feature pipelines, and read-heavy APIs. It’s less appropriate for:
- Complex transactional workloads — PostGIS still wins for concurrent read-write with ACID guarantees
- Sub-millisecond latency — object storage round-trips (~10-50 ms) are too slow for some real-time applications
- Heavily interconnected vector data — topology-preserving edits and network routing over live edits benefit from a proper spatial database