PostGIS: twenty years of geometry inside PostgreSQL

This file exists to redirect you, and that is the first fact

The GitHub README opens by saying the file is here to play nicely with modern code repository facilities, and that the actual readme is `README.postgis` in the same repository. That is the entire framing of this mirror: it exists so the project has a GitHub presence, stars, and issue-adjacent discoverability, while the substance lives elsewhere.

The rest of the file is a list of where things actually are. Official code repository, issue tracker and wiki: the OSGeo Trac instance at trac.osgeo.org/postgis. Build status and continuous integration: postgis.net/ci, plus GitHub Actions workflows, OSGeo Woodie pipelines, and CI scripts in the `ci/` directory. Developer setup notes: a `doc/development` guide on OSGeo Gitea, also published at postgis.net/development/docs. Official source tarball releases: postgis.net/development/source_code.

Two hosting systems are named and they are not interchangeable. GitLab and Gitea and Woodie and Woodpecker all appear in the repository tree alongside GitHub, so this project genuinely runs parallel infrastructure for the same code. When a README tells you where the issue tracker is, it is because opening the wrong one means your bug report goes nowhere.

Where the code lives inside the tree

Even a redirect README comes with a repository listing, and the listing is the useful part for anyone deciding whether to adopt PostGIS.

`postgis/` is the core vector library. `raster/` is a separate subsystem for raster data, which is the feature that surprises people: PostGIS is not only points and polygons. `topology/` implements the topological data model with nodes, edges and faces and snap-tolerance constraints. `liblwgeom/` is the geometry library with its own parsers and serializers, and `libpgcommon/` is shared PostgreSQL plumbing. `loader/` is the extension loader. `macros/` holds the type rewriting machinery, which is what makes the extension possible at all rather than merely a set of functions.

Around those sit the operational parts. `regress/` is the regression test suite, and for a geometry library the existence of a large one is a real quality signal, because edge cases in coordinate transforms and topology are exactly where a permissive library quietly returns wrong answers. `fuzzers/` is unusual to see listed and suggests input parsing is being fuzzed. `extras/` holds additional tooling. `sfcgal/` relates to the SFCGAL geometry backend. `doc/` is documentation. `utils/` has maintenance scripts.

There are also `spatial_ref_sys.sql` at the root, which is the coordinate reference system table shipped as a script, `configure.ac` with `autogen.sh` for autoconf, `GNUmakefile.in`, `astyle.sh` and `.clang-format` for formatting, and `codespell` config for spelling in documentation.

Building requires configure, and GNU make

The `Makefile` at the root is a shim, and it is unusually strict about two things. It states that it was copied and adapted from the PostgreSQL source to allow easy build on BSD systems, which tells you where the build conventions come from.

The first thing it does is check for a `GNUmakefile`. If that file is absent, it tells you that you need to run the configure program first and points you at `README.postgis` for installation instructions, then fails.

all install uninstall staged-install clean distclean maintainer-clean test check docs docs-install docs-uninstall utils:
	@if [ ! -f GNUmakefile ] ; then \
		echo "You need to run the 'configure' program first. See the file"; \
		echo "'README.postgis' for installation instructions" ; \
		false ; \
	fi

The second thing is that it walks your `PATH` looking for `gmake`, `gnumake` or `make`, testing each with `--version` and grepping for GNU, and refuses to proceed if none is GNU make. The error message is You must use GNU make to build PostGIS. On a Linux box with build-essential that is a non-issue; on macOS or BSD it is the first thing you will hit, and `gmake` is the answer.

One target is worth calling out because it explains why full Git history matters. `check-contributor-credits` is annotated as needing to work before configure, so that dedicated CI can audit contributor credits from a clean checkout with full Git history. If you shallow-clone the repository, that audit cannot run.

Contributing, translating, and where to ask questions

The contributor path is documented across several places and it is worth following it exactly. The README refers to contributing guidelines in `CONTRIBUTING.md`, and says developer workflow, build, test, release, and documentation notes live in the `doc/development` guide. The tree also has `CODE_OF_CONDUCT.md`, `SECURITY.md`, `CREDITS`, `NEWS` and `AGENTS.md`.

Translation runs on Weblate through the OSGeo instance. The README's instructions are that if you want to help, log into OSGeo Weblate, and that if you do not already have an OSGeo account you can create one at id.osgeo.org. An OSGeo account allows participating in translating both the PostGIS workshop and the PostGIS documentation, and also submitting bug tickets. That last clause is the important one: the account is the gate to the tracker as well as to the translation platform.

The chat is Matrix, room `#postgis:osgeo.org`, and it is bridged to IRC at `irc://irc.libera.chat/#postgis`, with a web client linked for people without an IRC client. A project with a 20-year history and an OSGeo institutional home tends to keep its IRC bridge running long past when anyone would choose IRC, and the bridge is the reason old mailing-list habits still work.

GitHub reports the primary language as PLpgSQL and GPL-2.0, with topics covering geospatial, gis, postgis, postgresql and c.

Project scale, and what the mirror does not show you

The metadata: 2238 stars, 436 forks, 59 open issues, not archived, homepage postgis.net, last pushed 2026-09-28, and the description itself marks the repository as a mirror. There are no releases published on GitHub, which is consistent with a project whose official source tarballs live at postgis.net/development/source_code rather than in release assets.

So what does the mirror tell you and what does it not? It tells you that the project is alive, since the mirror is being kept current, and it gives you the canonical URLs. It does not give you the version, the changelog, or the bug list. The `NEWS` file in the tree is the release history and the official site is the documentation, linked as the PostGIS manuals at postgis.net/documentation.

One thing to set expectations about: the mirror's issue count of 59 is not the project's issue count, because the issue tracker is on Trac. If you are triaging how actively bugs get fixed, Trac is the number that means something, and the GitHub issue list is whatever gets filed here by people who filed it in the wrong place.

Editorial conclusion

PostGIS is the answer to a question that looks trivial and is not: how do you store and query geometry in the database you already run. Its depth is the reason to use it, with vector types in `postgis/`, raster in `raster/`, topology in `topology/`, the loader in `loader/`, macro and type-rewriting machinery in `macros/`, and a regression suite in `regress/` that has been catching geometry regressions for most of PostgreSQL's modern history. The practical instruction from this README is about where things live. Clone from the OSGeo repository rather than the mirror if you intend to push, file bugs on trac.osgeo.org, and read `README.postgis` for installation rather than the file you are looking at now. It is GPL-2.0, still actively developed, with the GitHub mirror last pushed on 2026-09-28 and 2238 stars.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. postgis/postgis on GitHub
4. Project website
5. README