GeoParquet vs. GeoJSON - Performance, File Size, & Cloud-Native GIS Compared

Last Updated: 2026-11-04

GeoParquet vs. GeoJSON: Which GIS Format Is Better for Large Datasets?

If you have ever tried opening a 2 GB GeoJSON file in QGIS or loading a multi-million-row polygon boundary file into an interactive map, you already know the sinking feeling of a frozen screen and an out-of-memory crash.

For more than a decade, GeoJSON has served as the universal lingua franca of web cartography. It is transparent, human-readable, and supported out-of-the-box by nearly every web mapping library and REST API on the internet.

However, modern GIS workflows look radically different than they did in 2008. Today’s geospatial practitioners routinely ingest gigabytes (or terabytes) of IoT mobility telemetry, nationwide building footprints, satellite-derived segmentation masks, and high-frequency climate grids.

When applied to datasets at this scale, GeoJSON does not just slow down—it completely bottlenecks data architectures.

Enter GeoParquet, an open, standardized geospatial extension to Apache Parquet incubating within the Open Geospatial Consortium (OGC).

In this comprehensive guide, we compare GeoParquet and GeoJSON across architecture, storage efficiency, read/write throughput, cloud readiness, and developer ergonomics to answer a critical question: Which format should you choose for large datasets?

1. Structural Architecture: Text vs. Binary Columnar

To understand why these formats perform so differently at scale, you have to look under the hood at how each represents coordinate values and tabular metadata.

+--------------------------------------------------------------+
|                          GeoJSON                             |
|  - Text-based JSON (UTF-8)                                   |
|  - Row-oriented array of feature objects                     |
|  - Plain-text coordinate arrays (e.g., "[ -122.41, 37.77 ]")  |
|  - Requires full document parse to read one property         |
+--------------------------------------------------------------+
                               VS
+--------------------------------------------------------------+
|                        GeoParquet                            |
|  - Binary columnar storage (Apache Parquet)                  |
|  - Dictionary, RLE, and Snappy/Zstd compression              |
|  - Geometries encoded as WKB (Well-Known Binary)             |
|  - Supports column projection and row-group pushdown         |
+--------------------------------------------------------------+

GeoJSON: Row-Oriented, Text-Encoded JSON

GeoJSON represents data as an array of JSON objects. Every single feature explicitly repeats attribute keys alongside an array of string-encoded floating-point numbers:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": { "county": "Travis", "state": "TX", "pop_density": 1845.2 },
      "geometry": {
        "type": "Point",
        "coordinates": [-97.74306, 30.26715]
      }
    }
  ]
}

Because GeoJSON is text-based:

• Repetitive Schemas: Field names like "properties", "type", and "coordinates" are repeated millions of times, bloating the raw file size.
• Costly String-to-Float Conversion: Your CPU must parse text characters ("-", "9", "7", ".", "7"...) into 64-bit IEEE double-precision floats before performing any spatial operation.
• Monolithic Read Requirements: Standard JSON parsers must ingest the entire file into memory to construct the Document Object Model (DOM). Reading one attribute requires parsing every single feature.

GeoParquet: Column-Oriented, Binary-Encoded Data

GeoParquet builds directly on Apache Parquet, storing spatial tables column-by-column rather than row-by-row.

Attributes like county are stored in contiguous blocks, allowing advanced compression techniques such as run-length encoding (RLE), bit-packing, and dictionary compression. Geometry data is standardized as Well-Known Binary (WKB), accompanied by embedded JSON metadata detailing spatial reference systems (CRS), bounding boxes, and geometry types.

Because GeoParquet is binary and columnar:

• Zero Coordinate Parsing Cost: Geometries are stored directly in binary form, bypassing expensive string-to-float conversions.
• Projection Pushdown: If your downstream workflow only needs the county and pop_density columns, the reader fetches only those byte offsets from disk or S3, completely skipping the geometry column.
• Row-Group Partitioning: Parquet files split records into self-contained “Row Groups” (often 100,000 to 1,000,000 rows each) complete with min/max statistics for every column.

2. Head-to-Head Comparison: The Core Metrics

3. Storage Efficiency and File Size Benchmarks

When scaling from thousands to millions of records, storage disparities widen dramatically.

In standard benchmarks using real-world open spatial records (such as OpenStreetMap building footprints, US Census TIGER boundaries, and global ship AIS logs), GeoParquet routinely achieves 70% to 85% storage reductions compared to raw GeoJSON, and beats .geojson.gz by an additional 20% to 40%.

Why is GeoParquet so much smaller?

1. Dictionary Encoding: Repeated string attributes (e.g., state codes, land-use classifications) are indexed into tiny integer pointers rather than stored repeatedly as long strings.
2. Compact Binary Coordinates: A 2D point in GeoJSON takes around 30 to 45 bytes of ASCII text ([-122.4194155, 37.7749295]). In WKB, that same coordinate pair requires exactly 16 bytes.
3. Modern Compression Algorithms: Zstandard (Zstd) and Snappy compress columnar byte arrays much more effectively than standard Gzip can compress interleaved row-based text.

4. Query Performance and Cloud-Native Workflows

The biggest differentiator for large datasets is not just storage—it is query latency and memory utilization.

1. Selective Reads via Column Projection

Imagine a 15 GB national parcel dataset containing 60 attributes (owner names, tax IDs, deed history, zoning codes, and complex multipolygon boundaries).

• In GeoJSON: If you want to compute the average assessed property value per zip code, your analytical engine has to download and parse all 15 GB, including millions of complex boundary vertices.
• In GeoParquet: Analytical engines like DuckDB, Apache Sedona, Polars, or AWS Athena read only the zip_code and assessed_value columns. Instead of transferring 15 GB, your engine downloads and scans less than 80 MB.

2. HTTP Range Requests on Cloud Storage

GeoParquet operates seamlessly as a cloud-native geospatial format.

Because Parquet files store internal offsets and metadata in their file footer, client libraries can issue HTTP GET Range: bytes=... requests to cloud object stores like Amazon S3, Google Cloud Storage, or Azure Blob Storage. Rather than downloading an entire multi-gigabyte file, the client reads the footer, identifies the exact byte offsets where relevant records live, and downloads only the required subsets.

Client (DuckDB / Python / QGIS)
       │
       ├── 1. Read footer metadata (HTTP Range Request) ───► Cloud Storage (S3 / GCS)
       │                                                              │
       ◄── 2. Returns column offsets & row-group stats ───────────────┘
       │
       ├── 3. Read ONLY requested column chunks & ranges ─────────────►
       │                                                              │
       ◄── 4. Fast binary stream (minimal I/O & egress) ──────────────┘

5. Software Ecosystem & Tooling Support

Historically, GeoJSON’s primary advantage was universal tooling support. While that remains true for browser environments, GeoParquet’s ecosystem has matured rapidly:

• Desktop GIS: Native read/write support in QGIS 3.28+, ArcGIS Pro, and GDAL/OGR 3.5+.
• Analytical Engines & Languages: Fast vectorized read/write capabilities across Python (GeoPandas, pyarrow), R (sf), DuckDB (via the spatial extension), Apache Sedona, and Snowflake.
• Big Data Pipelines: Native integration across Apache Spark, Trino, Presto, and Databricks.
• Client-Side Web Maps: Lightweight WebAssembly libraries (such as parquet-wasm and duckdb-wasm) now allow web browsers to query GeoParquet files directly on client devices without a dedicated GIS middleware server.

6. Practical Decision Matrix: When to Use Which?

                                Dataset Size & Use Case
                                           │
             ┌─────────────────────────────┴─────────────────────────────┐
             ▼                                                           ▼
     Under 50–100 MB                                              Over 100 MB
(API payloads, simple maps)                                (Data warehousing, big data)
             │                                                           │
             ▼                                                           ▼
      Use **GeoJSON**                                            Use **GeoParquet**
• Direct Mapbox/Leaflet integration                        • High compression ratios
• Human-readable inspection                                • Sub-second analytical queries
• Standard REST API responses                              • Direct S3/GCS HTTP range reads

Choose GeoJSON If:

• Your dataset is under 50 MB to 100 MB.
• You are returning lightweight payload responses from a REST API to frontend clients.
• You are building lightweight web maps using Leaflet, MapLibre, or Mapbox GL JS without intermediate translation layers.
• You require rapid manual editing or inspection in a standard code or text editor.

Choose GeoParquet If:

• Your dataset exceeds 100 MB, or contains hundreds of thousands of complex spatial features.
• You are storing vector assets in cloud object storage (S3, GCS, MinIO, Azure Blob).
• You run spatial SQL analytics, feature engineering, or machine learning pipelines using Python, DuckDB, Spark, or Databricks.
• You want to reduce storage costs, avoid network egress fees, and eliminate memory crashes.

7. Migration Example: Converting GeoJSON to GeoParquet

Converting existing spatial assets to GeoParquet takes just a few lines of code.

Using Python (GeoPandas)

import geopandas as gpd

# 1. Read the legacy GeoJSON file
gdf = gpd.read_file("large_boundaries.geojson")

# 2. Write directly to GeoParquet using modern Zstandard compression
gdf.to_parquet("large_boundaries.parquet", compression="zstd")

Using GDAL / OGR (CLI)

ogr2ogr -f Parquet \
  -oo LCO:COMPRESSION=ZSTD \
  large_boundaries.parquet \
  large_boundaries.geojson

Using DuckDB

INSTALL spatial;
LOAD spatial;

-- Direct convert via SQL
COPY (
  SELECT * FROM ST_Read('large_boundaries.geojson')
) TO 'large_boundaries.parquet' 
WITH (FORMAT PARQUET, COMPRESSION 'ZSTD');

8. Summary: The Verdict on Large Datasets

For small datasets and direct web endpoints, GeoJSON remains a reliable, hassle-free utility format.

However, for large datasets, GeoParquet is objectively superior in every operational category. It delivers smaller file footprints, significantly lower storage overhead, near-instant spatial reads, and native integration with modern cloud data warehouses.

If your geospatial pipelines are groaning under the weight of oversized GeoJSON files, switching to GeoParquet is one of the most effective infrastructure upgrades you can make.

Frequently Asked Questions (FAQ)

Q1. Is GeoParquet an officially recognized GIS standard?
Yes, GeoParquet is an official open standard maintained under the guidance of the Open Geospatial Consortium (OGC).

Q2. Can I render a GeoParquet file directly in web mapping libraries like Leaflet or Mapbox GL JS?
While not natively parsed like GeoJSON, you can render GeoParquet in browsers using WebAssembly packages like parquet-wasm or by converting files to Vector Tiles (PMTiles/MVT) on ingestion.

Q3. Does GeoParquet support multiple coordinate reference systems (CRS)?
Yes, unlike GeoJSON (which is strictly restricted to WGS 84 / EPSG:4326 by RFC 7946), GeoParquet allows custom CRS definitions directly inside its embedded file metadata.

Q4. How does GeoParquet compare to FlatGeobuf for large spatial datasets?
FlatGeobuf is optimized for streaming spatial features directly to interactive web maps using R-Tree spatial indexing, whereas GeoParquet is designed for high-performance columnar analytics, compression, and massive data lake warehousing.

Q5. Can I open GeoParquet files inside desktop GIS software like QGIS?
Yes, modern versions of QGIS (version 3.28 and above) support dragging, dropping, viewing, and styling GeoParquet files without requiring third-party plugins.

See Also

GIS File Formats at FileFormat.com

Top 5 GIS File Formats for Google Maps

File Format News

File Format Forums