I've been spending a lot of time over the last few years building applications around PostGIS. One thing I keep noticing is that many developers immediately reach for a custom Django or FastAPI backend to expose their spatial data. While there's nothing wrong with that approach, it often means writing hundreds or thousands of lines of code that already exist in mature open-source projects.

PostGIS is just the database. The interesting part is how you expose that data to applications, web maps, mobile clients, or other GIS software.

Depending on the problem you're solving, there are several excellent tools available, and each has a different purpose. They're not really competitors—they're designed to solve different problems.

Here are the ones I find myself recommending most often.

pg_tileserv — When Your Goal is Rendering Maps

The first question I usually ask is:

"Do you need the data, or do you need to draw the data?"

If the answer is draw the data, then pg_tileserv is probably the right choice.

Instead of returning thousands (or millions) of features as GeoJSON, pg_tileserv converts your PostGIS data into Mapbox Vector Tiles (MVT) on demand.

Your browser only downloads the small tiles it needs, making maps incredibly responsive even with very large datasets.

A typical flow looks like this:

PostGIS
    │
pg_tileserv
    │
Vector Tiles (.pbf)
    │
OpenLayers / MapLibre / Leaflet

I particularly like pg_tileserv because there's almost no setup involved. Point it to your database, and it automatically discovers your spatial tables, views, and even SQL functions.

For applications where the primary objective is visualization, it's difficult to beat.

I use pg_tileserv when:

Building interactive Web GIS
Displaying millions of features
Creating dashboards
Developing SaaS mapping products
Performance is the top priority

pg_featureserv — When the Frontend Needs the Actual Features

Sometimes a frontend doesn't want tiles.

It wants the actual geometry.

Maybe the user clicks on a parcel.

Maybe they edit a feature.

Maybe they're downloading data.

That's where pg_featureserv fits perfectly.

Instead of serving vector tiles, it serves GeoJSON.

PostGIS
    │
pg_featureserv
    │
GeoJSON API
    │
Frontend

The nice part is that you don't need to write dozens of API endpoints.

Your tables become REST endpoints automatically.

Need parcels?

/parcels/items

Need roads inside a bounding box?

/roads/items?bbox=...

Need data generated from a SQL function?

It can expose that too.

Whenever someone says "My frontend just needs GeoJSON," pg_featureserv is usually the first tool that comes to mind.

PostgREST — My Favourite for Business APIs

This one surprises a lot of GIS developers.

PostgREST isn't a GIS tool.

It's a PostgreSQL tool.

And that's exactly why it's so useful.

Since PostGIS is simply an extension of PostgreSQL, PostgREST exposes geometry columns just like any other column.

The difference is that it isn't focused on maps—it focuses on building complete REST APIs.

Imagine you have:

Users
Projects
Organizations
Assets
Permissions
Spatial layers

PostgREST exposes everything.

PostgreSQL
      │
PostgREST
      │
REST API

Instead of creating dozens of CRUD endpoints in Django or FastAPI, you get them almost instantly.

I wouldn't replace my backend completely with PostgREST, but for internal systems and admin applications, it can remove an enormous amount of boilerplate.

pygeoapi — If Standards Matter

The geospatial industry is gradually moving away from older SOAP-like OGC services toward modern REST APIs.

That's where pygeoapi comes in.

It implements the new generation of OGC API standards.

Rather than thinking in terms of WMS or WFS, you start thinking in terms of:

OGC API Features
OGC API Tiles
OGC API Coverages
OGC API Processes

If you're building a Spatial Data Infrastructure (SDI), working with government agencies, or participating in projects where standards compliance is important, pygeoapi is worth exploring.

I also like that it's written in Python, making it relatively approachable for developers already familiar with the Python ecosystem.

GeoServer — Still the Workhorse

Every few months someone asks,

"Is GeoServer dead?"

Not even close.

GeoServer continues to be one of the most capable open-source GIS servers available.

If someone asks for:

WMS
WFS
WMTS
Styled layers
Raster publishing
Enterprise security
Desktop GIS compatibility

GeoServer is usually still the answer.

PostGIS
    │
GeoServer
    │
WMS / WFS / WMTS
    │
QGIS, ArcGIS, Web Apps

It's undoubtedly heavier than the other tools I've mentioned, but that's because it's solving a much broader problem.

If your consumers include desktop GIS software, legacy enterprise systems, or organizations that require OGC-compliant services, GeoServer remains incredibly valuable.

So... Which One Should You Use?

This is probably the wrong question.

A better question is:

"What are you trying to expose?"

If your goal is rendering fast web maps, use pg_tileserv.

If your frontend needs GeoJSON, use pg_featureserv.

If you're exposing your entire PostgreSQL database as a REST API, use PostgREST.

If you need modern OGC API standards, look at pygeoapi.

If your users expect WMS, WFS, or enterprise GIS interoperability, GeoServer is still hard to beat.

My Typical Architecture

For most of the systems we build, I don't see these tools as alternatives. They each solve a different part of the problem, so it's common to use more than one.

                React / OpenLayers
                       │
        ┌──────────────┼──────────────┐
        │              │              │
  pg_tileserv   pg_featureserv   PostgREST
                       │
                 PostgreSQL + PostGIS
                       │
          GeoServer / pygeoapi (when needed)

A web map might consume vector tiles from pg_tileserv, while the same application retrieves feature details through pg_featureserv. The admin portal talks to PostgREST for business data, and if a client requests OGC-compliant services, GeoServer or pygeoapi can expose the same underlying database without duplicating data.

Tools around PostGIS that you need to check