Should an Earth data team use QGIS or ArcGIS Pro?

Use QGIS when you want zero per-seat licensing, full GDAL/PROJ access, and Python (PyQGIS) scripting. Choose ArcGIS Pro when you need its geostatistical and 3D analyst extensions, enterprise SDE geodatabases, or interoperability with an existing Esri estate. Many teams run both.

When do you need PostGIS instead of files?

Move to PostGIS once multiple analysts edit the same data, datasets exceed a few hundred MB, or you need spatial indexes and SQL joins. Files like GeoPackage are fine for single-analyst projects and delivery, but they do not handle concurrent writes well.

Where does Google Earth Engine fit in a GIS stack?

Earth Engine is best for planetary-scale raster processing over public archives (Sentinel, Landsat) where you do not want to download terabytes. It is weak for editing, cartography, and storing proprietary vector data, so it usually feeds a desktop or PostGIS stack rather than replacing it.

How do GDAL and Python fit into a reproducible workflow?

GDAL/OGR is the processing engine under almost every GIS, callable from the command line or from Python (rasterio, geopandas, PyQGIS). Scripting the heavy steps makes them repeatable and auditable, which graphical menus alone cannot guarantee.

Choosing a GIS Stack for Earth Data Teams

The short answer

There is no single best GIS. A working Earth data stack is a small set of tools assigned to distinct jobs: a desktop GIS for inspection, editing and cartography (QGIS or ArcGIS Pro); GDAL/OGR for batch raster and vector processing; PostGIS when several people query the same data; a tiling or web layer for publishing; and, optionally, Google Earth Engine for planetary-scale archive processing. The design decision is not "which brand" but "which tool owns which step, and where do the handoffs happen."

For a geology or terrain team the practical levers are four: how much data you move, how often you repeat the same processing, whether the licensing model fits your funding, and what you must publish. Get those right and the tool names almost fall out on their own.

The five roles a stack has to fill

Most Earth data work maps onto five roles. A healthy stack names a primary tool for each and avoids forcing one tool to do all five.

1. Interactive desktop GIS

This is the analyst's cockpit: load a DEM, check a CRS, digitise a fault trace, style a map, run a one-off slope calculation. The two serious choices are QGIS (currently the 3.40 LTR line) and ArcGIS Pro.

QGIS is free, ships GDAL and PROJ under the hood, and exposes everything through the Processing Toolbox and PyQGIS. It reads ~100 raster and ~90 vector formats out of the box and connects directly to PostGIS. For most geological mapping, terrain derivatives, and cartography it is fully sufficient.

ArcGIS Pro earns its license cost in specific situations: the Geostatistical Analyst (kriging, cokriging, empirical Bayesian kriging), mature 3D and lidar handling, the Spatial Analyst raster algebra, ModelBuilder, and tight integration with enterprise geodatabases (SDE on SQL Server/PostgreSQL/Oracle) and ArcGIS Online. If your client or partner runs Esri, interoperability alone can justify it.

A common and entirely defensible pattern is QGIS for daily analysis and cartography with one or two ArcGIS Pro seats kept for geostatistics and client deliverables.

2. Batch processing engine

Once you are reprojecting 400 scenes or computing hillshade across a national DEM, the GUI is the wrong tool. GDAL/OGR is the engine underneath nearly every GIS, and calling it directly is faster and reproducible:

# Reproject and tile a DEM to a projected CRS, with compression
gdalwarp -t_srs EPSG:32631 -tr 30 30 -r bilinear \
  -co COMPRESS=DEFLATE -co TILED=YES srtm.tif srtm_utm31n.tif

# Hillshade and slope in one pass each
gdaldem hillshade -z 1.0 -az 315 -alt 45 srtm_utm31n.tif hs.tif
gdaldem slope -p srtm_utm31n.tif slope_pct.tif

Wrap these in a shell script or a Python pipeline (rasterio, geopandas, or PyQGIS in headless mode) and the same command runs identically on every machine. That repeatability is the real reason to script: a graphical menu sequence cannot be diffed, version-controlled, or re-run a year later with confidence.

3. Shared storage and query

For a single analyst, GeoPackage files are fine. The moment two people edit the same data, or a dataset grows past a few hundred MB, move authoritative storage into PostGIS. You gain GiST spatial indexes, SQL joins, row-level concurrency, and the ability to push analysis into the database:

-- Find boreholes within 500 m of a mapped fault, in a metric CRS
SELECT b.id, b.depth_m
FROM boreholes b
JOIN faults f
  ON ST_DWithin(
       ST_Transform(b.geom, 32631),
       ST_Transform(f.geom, 32631),
       500);

PostGIS becomes the single source of truth; QGIS, ArcGIS Pro, and web layers all read from it. Keep file formats for delivery and archive, not for the working copy.

4. Cloud / archive-scale raster

If your question is "NDVI trend across this 200,000 km² basin over ten years," downloading the imagery is the bottleneck. Google Earth Engine runs the computation server-side over its public catalog (Sentinel-2, Landsat, MODIS, climate reanalyses) and you export only the result. It is excellent for large-area, time-series raster work and poor at editing, cartography, and storing proprietary vector data. Treat it as a pre-processing tier that exports COGs or summary tables into your main stack.

5. Publishing

Decide the publishing model before you pick a library. Static or near-static layers are cheapest as pre-rendered vector tiles or Cloud Optimized GeoTIFFs served from object storage and drawn with MapLibre GL or Leaflet. Dynamic, query-driven data is better served from PostGIS through an OGC API – Features endpoint (pygeoapi) or a GeoServer/MapServer instance. The data model and tile strategy come first; the front-end library is the last decision, not the first.

A worked stack: a six-person terrain team

Take a team doing terrain risk screening and geological mapping for infrastructure clients.

Storage: PostGIS on a managed PostgreSQL instance holds all vector data and small rasters; large DEMs and imagery live as COGs in object storage.
Daily analysis: QGIS 3.40 LTR for everyone, reading directly from PostGIS.
Heavy processing: a Python repo (rasterio + geopandas + a few gdalwarp/gdaldem calls) for DEM derivatives and batch reprojection, run in CI so outputs are reproducible.
Specialist work: one ArcGIS Pro seat for kriging interpolation of sparse geotechnical points.
Large-area imagery: Earth Engine to derive multi-year change layers, exported as COGs.
Delivery: vector tiles plus a MapLibre viewer for clients; a pygeoapi endpoint for partners who want the raw features.

Every step has an owner, and every handoff is a defined format (PostGIS table, COG, vector tile) rather than an undocumented export.

Common mistakes and why they happen

Picking the tool before naming the workflow. "Is QGIS or ArcGIS better?" has no answer until you say what data, how much, and what output. The brand debate is a proxy for an unspecified workflow.
Choosing on license cost alone. Free is not free if it costs three weeks of scripting that a paid extension does in an afternoon, and paid is not justified if you never touch the extensions you bought.
Running repeatable jobs through the GUI. Anything you will do more than three times belongs in a script. The hidden cost is not the clicking; it is the inability to audit or reproduce the result.
Building a web map before the data model. Tile strategy and CRS decisions constrain everything downstream; choosing Leaflet vs MapLibre first solves the easy problem and leaves the hard one open.
Letting one tool own all five roles. Forcing PostGIS to do cartography, or QGIS to do nightly batch jobs, produces brittle workflows that depend on one person's memory.

Validation before you commit

Before standardising a stack, prototype the single riskiest step end to end: the largest reprojection, the heaviest interpolation, or the most demanding publishing case. Confirm that CRS, units, and geometry survive each handoff by checking a known control value at both ends. Document which tool produces which intermediate, and store those intermediates so the chain from raw data to deliverable is inspectable. A stack you cannot audit is a stack you cannot defend to a client.

Bathyl perspective

We are deliberately tool-agnostic: the stack is judged by whether it turns Earth data into a system that another analyst can inspect, re-run, and extend. In practice that usually means PostGIS as the source of truth, GDAL/Python for the repeatable heavy lifting, a desktop GIS for human judgement, and a publishing tier chosen last. The goal is a chain where every link is named and every handoff is a documented format.