Cloud-Native Geospatial Formats Explained: COG, GeoParquet, PMTiles & More

Last Updated: 13 Nov, 2026

What Are Cloud-Native GIS File Formats? A Developer’s Guide

If you have ever built a geospatial pipeline, you know the pain of the “download-first” bottleneck. Traditionally, if your application needed a 500x500 pixel bounding box from a 15 GB satellite scene—or wanted to filter ten rows from a 4 GB municipal parcel dataset—you had to download the entire file, parse it into memory, and then slice out the piece you actually cared about.

Simply uploading a Shapefile, GeoJSON, or standard GeoTIFF to an Amazon S3 bucket or Google Cloud Storage does not make it cloud-native. It just puts a legacy file on someone else’s hard drive.

Cloud-native GIS file formats solve this problem by restructuring how spatial data is organized on disk. Instead of forcing clients to read files sequentially from start to finish, these formats are engineered for direct, partial reads over the network. For developers, this unlocks serverless architectures, drastically reduces egress costs, and lets web clients query massive datasets directly from static object storage.

The Mechanics: How Cloud-Native Geospatial Actually Works

Before diving into specific file extensions, it helps to understand the underlying engineering pattern that makes them tick. Almost every cloud-native geospatial format relies on three core mechanisms:

1. HTTP Range Requests (GET with Range headers): Standard HTTP/1.1 and HTTP/2 support requesting specific byte ranges from a remote file (e.g., bytes=0-16383). Cloud object stores like AWS S3, Cloudflare R2, and Azure Blob Storage natively support this out of the box.
2. Front-Loaded (or Predictable) Metadata & Spatial Indexes: To ask for the exact bytes covering a geographic area, the client first needs a map of the file’s internal layout. Cloud-native formats store their header metadata and spatial indexes (like R-trees or bounding-box hierarchies) in a predictable location—usually the very beginning or very end of the file. A client makes one tiny initial request to read the index, calculates the exact byte offsets for the target region, and fetches only those chunks.
3. Internal Tiling and Chunking: Rather than storing rasters row-by-row or vectors as a flat text wall, data is partitioned into self-contained, compressed blocks (tiles, row groups, or N-dimensional chunks) that can be fetched and decompressed independently.

The Core Cloud-Native GIS File Formats

There is no single format that rules them all. Choosing the right one depends on whether you are dealing with imagery, tabular vectors, map tiles, multidimensional arrays, or LiDAR point clouds.

1. Cloud-Optimized GeoTIFF (COG) — For Raster Imagery

A COG isn’t a brand-new proprietary file type; it is a standard GeoTIFF (.tif) with a strict internal layout adopted as an official OGC standard. Because it remains a valid GeoTIFF, legacy desktop tools like QGIS and ArcGIS can still open it without breaking.

• How it works: Instead of storing pixels in horizontal scanlines across the whole image, a COG organizes pixels into internal tiles (commonly 512×512 pixels). It also embeds overviews (pre-computed, lower-resolution image pyramids) inside the same file. When a user zooms out on a web map, the client pulls low-res overview tiles; when they zoom in, it pulls only the high-res tiles intersecting the viewport.
• Best for: Satellite imagery, aerial orthomosaics, Digital Elevation Models (DEMs), and dynamic raster tile servers (like TiTiler).

Generating a COG via GDAL:

gdal_translate input.tif output_cog.tif \
  -of COG \
  -co COMPRESS=DEFLATE \
  -co OVERVIEWS=IGNORE_EXISTING

2. GeoParquet — For Big Vector Analytics & Data Warehouses

If your workflow looks more like data engineering than traditional cartography, GeoParquet (.parquet) is the heavy hitter. Built on top of Apache Parquet, it stores geometries as ISO-standard Well-Known Binary (WKB) alongside rich tabular attributes.

• How it works: Unlike Shapefiles or GeoJSON, which store data row-by-row, Parquet is columnar. If you run an aggregation on a population column across 50 million polygons, the engine skips reading the heavy geometry bytes completely. GeoParquet also embeds bounding-box metadata per row group (and supports spatial sorting via Hilbert curves or H3 indexes), allowing query engines to skip irrelevant chunks.
• Best for: Large-scale spatial analytics, cloud data warehouses (Snowflake, BigQuery, Databricks), and serverless SQL engines like DuckDB.

Querying remote GeoParquet directly with DuckDB:

INSTALL spatial;
LOAD spatial;

SELECT land_use, COUNT(*) AS parcel_count
FROM read_parquet('s3://example-bucket/parcels.parquet')
WHERE ST_Intersects(geometry, ST_MakeEnvelope(-122.5, 37.7, -122.3, 37.8))
GROUP BY land_use;

3. FlatGeobuf — For Streaming Vector Features to the Web

While GeoParquet shines in analytical engines, its footer-based metadata and column orientation aren’t always ideal for streaming raw vector geometries straight into a browser map. Enter FlatGeobuf (.fgb).

• How it works: Built on Google’s FlatBuffers binary serialization library, FlatGeobuf places a packed Hilbert R-tree spatial index right at the front of the file. Web clients (like MapLibre GL JS, Leaflet, or OpenLayers) can execute a bounding-box query over HTTP range requests and begin rendering features on the screen while the remaining bytes are still streaming in.
• Best for: Replacing multi-megabyte GeoJSON files in interactive web applications without spinning up a PostGIS/GeoServer backend.

4. PMTiles — For Serverless Vector & Raster Basemaps

Traditionally, serving interactive map tiles (/{z}/{x}/{y}.pbf) required either running a dedicated tile server (like Martin or Tileserver-GL) or uploading millions of tiny individual .pbf files to S3—a nightmare for bucket management and API request costs.

• How it works: Created by Protomaps, PMTiles (.pmtiles) packs an entire pyramid of Mapbox Vector Tiles (MVT) or raster tiles into a single archive file. It uses a clustered directory structure optimized for Hilbert-curve spatial locality, meaning a browser map library can fetch tiles directly from a single static file on S3 or Cloudflare R2 using HTTP range requests.
• Best for: Zero-backend custom basemaps, high-traffic web maps, and offline mobile mapping applications.

5. Zarr — For Multidimensional Scientific Data

NetCDF and HDF5 have dominated meteorology, oceanography, and climate modeling for decades, but their monolithic file structures struggle in distributed cloud environments. Zarr reimagines N-dimensional arrays for object storage.

• How it works: A Zarr store splits massive multidimensional arrays (e.g., time × latitude × longitude × altitude) into small, uniformly sized, compressed chunks. Each chunk is stored as an individual object (or consolidated via Zarr v3 sharding) with JSON metadata describing the array dimensions. Dozens of parallel workers can read or write different time slices simultaneously without file-locking conflicts.
• Best for: Time-series satellite datacubes, weather forecasts, climate models, and distributed Xarray/Dask pipelines.

6. Cloud-Optimized Point Cloud (COPC) — For LiDAR

Built as an extension to the standard LAZ 1.4 compressed LiDAR format, COPC (.copc.laz) organizes 3D point clouds into a clustered octree structure. Like COG, it remains backwards-compatible with existing LAS/LAZ readers while allowing web viewers (such as Potree or deck.gl) to stream points based on camera frustum and level-of-detail without downloading multi-gigabyte point clouds.

Developer Decision Matrix: Which Format Should You Choose?

Critical Gotchas When Deploying to Production

Moving to cloud-native formats simplifies your backend, but it shifts configuration responsibility onto your cloud storage layer. Watch out for these three common pitfalls:

1. Forgetting CORS Headers: If a browser application (using MapLibre, OpenLayers, or geotiff.js) makes an HTTP range request to your S3 bucket, the bucket’s Cross-Origin Resource Sharing (CORS) policy must explicitly allow the Range header in AllowedHeaders and expose Content-Range, Content-Length, and Accept-Ranges in ExposeHeaders. Without this, requests will silently fail in the browser.
2. Unsorted GeoParquet Row Groups: Converting a messy Shapefile straight to GeoParquet won’t automatically make bounding-box queries fast. If features are scattered randomly across row groups, the query engine still has to scan every row group. Always sort your geometries spatially (e.g., using a Hilbert curve via geopandas or DuckDB before writing) so spatially proximate features live in the same row groups.
3. Suboptimal Chunk/Tile Sizes: Tiny chunks (e.g., 64×64 pixels) trigger thousands of HTTP requests, increasing latency and cloud API costs. Massive chunks (e.g., 4096×4096 pixels) force clients to over-fetch data. Stick to standard defaults—512×512 pixels for COGs and 10 MB to 100 MB per chunk for Zarr or GeoParquet row groups.

Wrapping Up

Cloud-native GIS file formats represent a fundamental shift from moving data to compute toward moving compute (and lightweight range requests) to data. By pairing formats like COG, GeoParquet, FlatGeobuf, and PMTiles with STAC (SpatioTemporal Asset Catalog) metadata, developers can build resilient, planetary-scale mapping and analytics pipelines on top of inexpensive static object storage—no heavy spatial database required.

Frequently Asked Questions (FAQ)

Q1. What makes a GIS file format “cloud-native”? A format is cloud-native when it pairs a front-loaded spatial index with internal tiling or chunking, allowing clients to fetch small geographic subsets over HTTP range requests without downloading the entire file.

Q2. Do I need a dedicated GIS server to host COG, GeoParquet, or PMTiles files? No—you can host them on any standard static object storage that supports HTTP range requests, such as AWS S3, Google Cloud Storage, Azure Blob Storage, or Cloudflare R2.

Q3. Should I use GeoParquet or FlatGeobuf for my vector data? Use GeoParquet for heavy analytical queries, SQL engines (like DuckDB), and data warehouses, and use FlatGeobuf when streaming raw vector features directly to a browser map.

Q4. Is a Cloud-Optimized GeoTIFF (COG) compatible with traditional desktop GIS software? Yes, because a COG is strictly a standard GeoTIFF with internal tiles and overview pyramids, it opens seamlessly in legacy tools like QGIS, ArcGIS Pro, and GDAL.

Q5. How does PMTiles differ from MBTiles? MBTiles relies on a SQLite database (which requires server-side code to query over the web), whereas PMTiles organizes tiles into a static archive that web browsers can read directly via HTTP range requests.

See Also

Best GIS File Formats for Mobile Apps

GIS File Formats at FileFormat.com

Top 5 GIS File Formats for Google Maps

File Format News

File Format Forums