GeoServer vs pygeoapi vs QGIS Server: which to use
Choose GeoServer, pygeoapi or QGIS Server by protocol version, styling, editing and application contract, with a concrete selection matrix.
Editorial review: 2026-09-23
Choose the server according to the artifact you need to publish and the clients that must consume it. GeoServer, pygeoapi and QGIS Server overlap in some interfaces, but their configuration and cartographic workflows differ. Deploying all three by default adds work without guaranteeing a better product.
Start with the output
If the central artifact is a carefully styled QGIS project and its print layouts, evaluate QGIS Server's project-driven publication. If you need an established map/feature service catalog with GeoServer administration and its supported protocols, evaluate GeoServer. If the primary contract is a resource-oriented data API and Python provider/process integration, evaluate pygeoapi. These are starting hypotheses to test, not exclusive product categories.
| Requirement | GeoServer | pygeoapi | QGIS Server |
|---|---|---|---|
| Publication configuration | Workspaces, stores, layers and styles | YAML resources and provider plugins | QGIS project plus server configuration |
| Server cartography | Styles and WMS rendering | Verify required map capabilities/provider; not a QGIS-project renderer | QGIS rendering and project configuration |
| Feature access | WFS and supported API extensions | OGC API Features and provider capabilities | WFS and OGC API Features in documented version |
| Existing desktop workflow | Translate styles and service configuration | Separate API schema from desktop project | Reuse project as publication input, then test |
| Python-centric API customization | Extension/integration choices | Provider/process plugin model | Plugins and application integration |
| Operational dependencies | Java runtime, data directory, sources | Python environment, config, providers | QGIS server environment, project, fonts and sources |
| First proof | Map image plus feature query | Collection, item and filter | Project render, print and client request |
Check exact versions and optional modules. QGIS Server 3.44 services lists its supported protocols. GeoServer services and pygeoapi 0.24.0 providers describe their own boundaries. A generic “supports OGC” checkbox is too imprecise for procurement.
Test the hardest requirement first
For a cartographic publication, use an actual layout with labels, fonts, scale-dependent symbols and legend. Compare screen and print outputs on the server host, where fonts and file paths may differ from a designer's workstation. If output fidelity is the main risk, a feature API smoke test does not answer it.
For an API product, begin with stable IDs, schema, filters, pagination, CRS and error behavior. Use a fixture with empty results, invalid parameters and missing IDs. If a client depends on WFS 2.0 semantics, verify that precise version; do not infer it from the presence of another WFS version.
For editing, investigate provider support and the complete authorization/validation workflow. A server's transaction capability does not automatically supply approval, attachments, offline sync or versioned business workflows. Decide which component is authoritative for writes.
Reuse one data source without duplicating responsibility
Several services can publish approved views of one PostGIS database, provided credentials, schemas and query load are controlled. Assign a stable ID and update policy to the data product. Avoid letting each server independently transform and reinterpret the same source without tests; consumers can then receive inconsistent values from two apparently equivalent interfaces.
A reasonable combined design might use GeoServer for legacy WMS consumers and pygeoapi for a new public API. That is justified by two concrete contracts. Another design might use QGIS Server alone because a maintained QGIS project satisfies both map and feature consumers. Prefer the smallest set that meets the requirements and can be operated reliably.
Compare administration and recovery
Ask who publishes a new layer, reviews fields, updates styles, patches the runtime and restores a failure. Rehearse the work using the actual team's skills. An interface familiar to one expert may be difficult for the next operator if configuration and dependencies are undocumented.
| Failure | GeoServer dependency | pygeoapi dependency | QGIS Server dependency |
|---|---|---|---|
| Source unavailable | Store and credentials | Provider and credentials | Project source and credentials |
| Output changed | Style/runtime revision | Schema/provider revision | Project/font/runtime revision |
| Recovery on new host | Data directory plus sources | Config/environment plus sources | Project/environment plus sources |
| Consumer cannot discover | Capabilities and permissions | Links/conformance/OpenAPI | Project service settings and permissions |
Make the decision with evidence
The reference lab contains local GeoServer and pygeoapi checks with explicit data stores and workloads. Their timings are not a head-to-head benchmark. QGIS project files are supplied separately; a syntactically valid project is not a rendered-server proof.
Use GeoServer publication or your first pygeoapi endpoint for the appropriate next experiment. Document the requirement satisfied, remaining exceptions and operating owner. That provides a better selection basis than ranking three logos or choosing the newest protocol name.