GeoServer vs QGIS Server vs MapServer: which map server to choose

In short

QGIS Server serves a QGIS project exactly as you built it in QGIS Desktop, with its styles, labels and print layouts. GeoServer publishes layers independent of any project, with its own SLD styles, and targets spatial data infrastructures. MapServer is the oldest, very fast, configured through a text file. Martin and pg_tileserv do one thing: serve vector tiles, mostly from PostGIS.

None is better in absolute terms. The right choice depends on your working tool, your users and the team that will maintain the server. In practice, the question is less about raw capability, since all of them implement the main OGC standards, than about workflow: where maps are designed, who maintains the configuration, and which clients will consume the services. A team that lives in QGIS Desktop will not choose the same way as a data infrastructure team that publishes hundreds of reference layers for external partners.

The servers side by side

All of these are open source. Languages and features listed are those of their respective projects; check the documentation of the version you install.

Styling: where the servers differ most

On paper, all these servers publish WMS. In practice, the difference you feel most day to day is how map appearance is described. That is what drives publishing time, rendering quality and ease of maintenance.

• QGIS Server reads the QGIS project directly: symbology, labels, scale rules, blending modes, print layouts. What you see in QGIS Desktop is what the server draws, because both share the same rendering libraries.
• GeoServer uses the SLD standard, a verbose but standardized XML format. Official extensions also let you write styles in CSS or YSLD, which are easier to read. A QGIS style can be exported to SLD, but advanced rendering (effects, geometry generators, some labels) is often lost along the way.
• MapServer describes styles in the mapfile, with CLASS and STYLE blocks and expressions that decide which class a feature belongs to. It can also read SLD. The format is compact and easy to review, but it is written by hand.
• Martin and pg_tileserv style nothing: they send geometries, and the style is a JSON document interpreted by the client library, for example MapLibre. Changing a color requires no server change.

The practical consequence: if your maps are rich and already polished in QGIS, every other server will ask you to translate those styles, then maintain two versions. If your layers are simple (fills, outlines, a few classes), the format matters little and other criteria, such as standards coverage or performance, take over. Test three of your most complex layers before deciding: it is the fastest way to measure the real effort.

GeoServer vs QGIS Server: the real question

For most teams working in QGIS, the choice is between these two. The deciding question: where do your styles live?

• Your maps are designed in QGIS and must look the same on the web as on screen: QGIS Server, with Lizmap on top for a complete portal (search, editing, printing).
• You share layers with partners who will use them in their own tools (ArcGIS, OpenLayers, a data catalog): GeoServer, built to publish standalone OGC services.
• You need both: this is common. A Lizmap portal for users, a GeoServer for reference services. A GeoServer layer can also be added to a QGIS project published in Lizmap like any WMS or WFS service.

At LizPack, both run side by side: LizPack Map includes QGIS Server, and GeoServer Cloud provides an isolated GeoServer workspace that links to your PostGIS database. For the Lizmap side, see hosting Lizmap or installing it yourself. A common case shows the split: a local government publishes its land-use plan in a Lizmap portal, with parcel search, A3 printing and staff editing of requests. The same zoning layers are published in GeoServer for the regional data portal, which harvests them every night. A single PostGIS database feeds both, and a fix made in the morning shows up everywhere.

MapServer: speed, at the cost of configuration

MapServer, born at the University of Minnesota and now an OSGeo Foundation project, remains a reference for serving large map volumes with few resources. Everything is described in a mapfile, a text file defining layers, sources and styles. MapServer also suits organizations that already manage infrastructure as code: a mapfile can be generated from templates, tested automatically and deployed like any other configuration file.

It is an excellent choice for a technical team comfortable with configuration files and version control. For GIS specialists who want to publish from an interface, GeoServer or QGIS Server will be more approachable.

MapServer is not limited to server mode: its MapScript bindings let you drive rendering from Python or other languages, to generate maps in batch or embed the engine in an application. The project, under an MIT-style license, is maintained by a steering committee within the OSGeo Foundation. Its mapfiles also fit well in a version control repository, so every change to a layer or style is reviewed and can be rolled back.

Performance: what really matters

Speed comparisons between servers circulate widely, but they rarely say much about your own case. On real data, the gap between two well-configured servers is often smaller than the gap between a well-prepared layer and a poorly prepared one on the same server. Before blaming the software, check these levers, which apply to all of them:

• Tile caching. GeoServer includes GeoWebCache; MapServer is often paired with MapCache; in front of QGIS Server, a tile cache avoids redrawing the same areas. A map viewed by many users should almost always go through a cache.
• The data source. An indexed PostGIS table responds far better than a large Shapefile or a file read from a slow network drive.
• Scale rules. Drawing every parcel of a country at small scale is costly and unreadable; limit each layer to the scales where it makes sense.
• Labels and effects. Labels with collision handling, shadows and layer effects are expensive. They, not the geometries, often slow down a published QGIS project.
• Rasters. A tiled, compressed GeoTIFF with overviews reads much faster than a raw image with the same content.

To compare fairly, measure the response time of the same GetMap request, on the same layer, with and without cache, at two or three scales. Keep those measurements: they will also help you confirm that a server update has not made anything worse.

Martin and pg_tileserv: vector tiles

Vector tiles (MVT format) send clipped geometries to the browser, where the client library (MapLibre, OpenLayers) draws them. The result is smooth and the style can change without touching the server. They fit heavily viewed public maps, custom basemaps and mobile apps well. They fit less well when users must print a standardized map, query full attributes or get exactly the same rendering in every software.

• Martin, a MapLibre community project, serves tiles from PostGIS, MBTiles or PMTiles.
• pg_tileserv, published by Crunchy Data, exposes PostGIS tables and functions as tiles with very little setup.
• Neither replaces WMS or WFS: they complement an OGC server for public web maps.

Both servers rely on PostGIS's ability to produce MVT tiles itself. The practical consequence: performance depends mostly on the database, its indexes and geometry complexity. Martin can also serve GeoJSON files and pre-generated tiles, which makes it a good choice for mixing live data and static basemaps.

What running each server takes

Choosing a server is a commitment for years. Beyond features, look at what it will take every month to keep it running: who knows how to configure it, how it is updated, and what it needs from the machine. Also note who on your team will hear about a security flaw and be able to apply the fix within the week: that is often the criterion that separates two servers with equivalent features. Write the answer down before choosing, with a name next to each server, because an unowned server is the one that ends up forgotten and exposed.

Two practical remarks. First, these servers are not mutually exclusive: many organizations run QGIS Server for their portals and GeoServer for their reference services, on the same PostGIS database. Second, the real cost is staff time. A server nobody on the team knows how to update eventually becomes a risk, however good it is. That is the work LizPack, an open source geospatial infrastructure, takes on by orchestrating these tools without replacing them: what LizPack does explains the split.

Common mistakes when choosing

• Choosing from a feature list. All four servers cover the main standards. What makes the difference is your workflow: where maps are created, who maintains them, who consumes them.
• Underestimating style translation. Moving from a polished QGIS project to equivalent SLD styles can take days per map. That cost belongs in the comparison.
• Forgetting the clients. A partner expecting WFS 2.0, a data portal harvesting GetCapabilities, a mobile app reading vector tiles: start from what they can read.
• Believing one server must do everything. A QGIS Server portal with Lizmap for users and a GeoServer for reference services, on the same PostGIS database, is a common and healthy architecture.
• Neglecting maintenance. The best server becomes a risk if it is never updated. Choose the one your team can really maintain, or hand that part of the work off.
• Testing on toy data. A test on ten features tells you nothing. Use your real layers, at their real volumes, with your styles.

A simple method works well: shortlist two candidates, publish the same three representative layers on each, display them in your users' clients, measure, then estimate the yearly maintenance time. Within one or two weeks the answer is usually clear, and it rests on your data rather than on reputations.

Choose based on your need

Whatever the server, it will need maintenance: Java or system libraries, certificates, security updates. The guide securing and updating GeoServer shows what that means in practice. If you keep QGIS Server and GeoServer side by side, use a shared naming rule for layers and document which layer is published where: users will know which URL to use, and you will avoid maintaining two diverging versions of the same data.

Frequently asked questions