Short answer

PostGIS and desktop GIS are not competitors; they occupy different layers of the stack. Desktop GIS (QGIS, ArcGIS Pro) is an interactive workspace for viewing, editing, styling, and exploratory analysis. PostGIS is a spatial database engine: storage, concurrency, indexing, and repeatable SQL processing, with no map canvas of its own. You move work into PostGIS when an operation must be rerun, shared by several people, applied to data too large for desktop memory, or made reproducible as code. In practice the right answer for a serious team is "both," with QGIS reading and editing PostGIS tables live.

What each tool actually is

Desktop GIS is a graphical application centred on a map canvas. Its strengths are everything that needs a human in the loop: panning through data to understand it, snapping and reshaping geometry by hand, building a print layout, tuning symbology and labels, and clicking through a one-off analysis where seeing each intermediate result matters. QGIS and ArcGIS Pro both bundle a large processing toolbox, but each run is an interactive event.

PostGIS is an extension to PostgreSQL that adds geometry and geography types, a spatial index (GiST), and several hundred spatial functions (ST_Intersects, ST_Buffer, ST_Transform, ST_Union, and so on). It has no display. You talk to it in SQL, and its job is to hold the authoritative data and execute spatial logic on the server, close to the data, with a query planner deciding how.

The cleanest way to see the split: desktop GIS answers "let me look at and shape this," PostGIS answers "store this reliably and compute this the same way every time."

The dimensions that actually decide it

Concurrency. A shapefile or GeoPackage is effectively single-writer. PostGIS gives you PostgreSQL's row-level locking and transactions, so a whole team can edit the same dataset at once. If more than one person touches the data, this alone often settles the question.

Repeatability. A QGIS analysis is a sequence of clicks that lives in someone's memory or, at best, a Processing model. A PostGIS analysis is a SQL script in version control. Six months later you rerun the script and get the identical result on updated data. For anything that recurs — monthly updates, audited deliverables — code beats clicks.

Data volume. Desktop GIS tends to load layers into memory and slows as features climb into the hundreds of thousands and millions. PostGIS reads only the rows a query touches via its spatial index and never needs the whole table in memory. A spatial join that crawls in QGIS can return in seconds in SQL.

Auditability. "How was this layer made?" has a clean answer when the answer is a SQL file. It has a vague answer when it was produced by interactive tools whose parameters no one wrote down.

Against all that, desktop GIS wins decisively on visualisation, cartography, interactive editing, and quick exploratory work where the overhead of writing SQL is not worth it.

A worked comparison

Suppose you must find every parcel within 500 m of a mapped fault, for a hazard screening that reruns whenever the fault map is revised.

In QGIS you would run Buffer on the faults (500 m), then Select by Location or Join attributes by location against parcels, then export. It works, and you can watch each step — good the first time. But the steps live in your hands, and rerunning next quarter means repeating them exactly.

In PostGIS it is one indexed statement:

SELECT p.*
FROM parcels p
JOIN faults f
  ON ST_DWithin(p.geom, f.geom, 500)   -- metres, projected CRS
GROUP BY p.gid;

ST_DWithin uses the GiST index to test only nearby candidates rather than buffering everything, so on a large parcel layer it is both faster and exact. Save it as hazard_screen.sql, rerun it after any fault update, and the result is reproducible by anyone. Note the CRS caveat: distances are only in metres if both layers are in a projected CRS such as a UTM zone — in EPSG:4326 the "500" would be degrees. That discipline matters in either tool.

The real pattern: use both

The professional default is PostGIS as the system of record and analysis engine, QGIS as the window onto it. QGIS connects to a PostGIS database as a native data source: you browse tables in the Browser panel, drag them onto the canvas, edit them with the standard digitising tools (changes write straight back to the database, transactionally), and run ad-hoc SQL through the DB Manager. ArcGIS Pro connects similarly via a database connection / query layers.

So a typical flow is: store the authoritative geology in PostGIS; edit and style it in QGIS; run the heavy, repeatable processing as SQL; and, when needed, publish straight from the same tables to a web service. Nobody chooses one tool for the whole lifecycle.

Common pitfalls and why they happen

  • Asking "which is better" with no workflow named. The honest answer is always "depends on the task." Better is faster, cheaper, more repeatable, more shareable — these point different ways for editing vs batch analysis.
  • Running every job in the desktop because it is familiar. A monthly process clicked by hand will eventually be done slightly differently and produce a different number. That is a repeatability failure dressed as convenience.
  • Trying to do cartography in PostGIS. It has no renderer. Symbology, labels, and layouts belong in the desktop tool.
  • Forgetting the spatial index. A PostGIS query with no GiST index can be slower than QGIS, which surprises people and makes them blame the database rather than the missing CREATE INDEX.

Validation when you have both

  • Run a known operation in QGIS and in PostGIS and confirm matching feature counts and extents — a quick way to catch a CRS or geometry-validity mismatch.
  • After editing PostGIS data in QGIS, verify validity server-side with ST_IsValid rather than trusting the canvas.
  • Keep SQL analysis scripts in version control so the audit trail is the artefact itself.

Bathyl perspective

We reach for PostGIS the moment GIS becomes shared infrastructure — multiple editors, recurring analysis, data too big for one laptop — and keep QGIS as the editing and cartography surface on top of it. The goal is never to replace the desktop; it is to put the authoritative data and the repeatable logic somewhere that survives turnover and scales, while humans still get a real map to look at.

Related reading

Sources