The not recommended note means you can compile and install with that, but you'll be missing some functionality.

Means it currently does or doesn't but may change at release time.

Note we have dropped support for PostgreSQL 8.3 in PostGIS 2.0.

We have dropped support for PostgreSQL 8.4 in PostGIS 2.1.

We have dropped support for PostgreSQL 9.0 in PostGIS 2.2.
We have dropped support for PostgreSQL 9.1 in PostGIS 2.3.

We do not encourage PostgreSQL 9.2 + PostGIS 1.5, however PostGIS 1.5.6+ has patches to work with 9.2.

If you are compiling PostGIS 2.0+ with anything less than 9.1,
you will not get CREATE EXTENSION support and will also not get KNN gist distance for geometry.

As a general rule, the PostGIS Project Steering committee tries to maintain support of PostGIS for at least
two versions of PostgreSQL. We most often support more than 2 PostgreSQL versions, if requirements do not
necessitate bumping up requirement without too much effort. We will rarely support more than 5 PostgreSQL
versions on any release.

64-bit Windows version support started in PostGIS 2.0.0 (both 9.0 and 9.1)

Versions of GEOS support for PostGIS

The below chart shows which versions of GEOS work with which versions of PostGIS.
The none means that you can get that version to work without GEOS, though its not recommended since a lot of functions will not be installed.

For the not recommended, this means that while you can get PostGIS to work with those versions, you'll be missing out on some PostGIS functions such as ST_Covers, ST_CoversBy and for PostGIS 1.5 the ST_HausdorffDistance and enhancements to ST_Buffer (both speed and functionality). GEOS 3.1 brought cascade union. GEOS 3.2 brought faster buffering and buffering enhancements, plus numerous enhancements with dealing with tolerance issues when unioning. GEOS 3.3 brought ST_ValidReason, ST_MakeValid etc (in the PostGIS 2.0 releases), so these functions will be disabled in PostGIS 2.0 if you are not running GEOS 3.3. GEOS 3.3. also brought stability fixes for union/buffer not back-ported to 3.2. For PostGIS 1.5, although 3.3 does not add any additional functions, it does fix some crashers involving buffering and unioning not present in other minor releases, so suggested to use that if you can.

GEOS 3.4 introduced interruptibility features that allow you to cancel a query while in a GEOS loops. Prior versions of PostGIS/GEOS a query could run (even with statement timeout) until you ran out of memory. This new feature requires both PostGIS 2.1+ and GEOS 3.4+. 3.4 also brought ​ST_DelaunayTriangles so you won't get that in 2.1 if you don't compile for 3.4+.

GEOS 3.6.0 came out after 2.3.0 release, so most 2.3 distros will not have enabled - ​ST_MinimumClearance* that require 3.6, but may in 2.3.1

Geos Version

PostGIS 1.3

PostGIS 1.4

PostGIS 1.5

PostGIS 2.0

PostGIS 2.1

PostGIS 2.2

PostGIS 2.3

PostGIS 2.4 (Trunk)

None

Yes (not recommended)

No

No

No

No

No

No

2.2

Yes (not recommended)

No

No

No

No

No

No

No

3.0

Yes

Yes (not recommended)

No

No

No

No

No

No

3.1

Yes

Yes

Yes (not recommended) (requires 3.1.1+)

No

No

No

No

No

3.2

Yes

Yes

Yes

Yes (not recommended)

No

No

No

No

3.3

Yes

Yes

Yes (preferred 3.3.3+)

Yes (3.3.9+)

Yes (not recommended)

Yes*

No

No

3.4

Yes

Yes

Yes (preferred 3.4.2+)

Yes (3.4.2+)

Yes

Yes*

Yes*

Yes*

3.5

Yes

Yes

Yes

Yes

Yes

Yes (recommended)

Yes*

Yes*

3.6

Yes

Yes

Yes

Yes

Yes

Yes

Yes (recommended)

Yes

3.7*

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Versions of GDAL support for PostGIS
PostGIS raster functionality (introduced in 2.0) depends on GDAL so to get raster functionality, you'll need to compile with GDAL support and preferrably
1.9 or above. Although you can compile PostGIS 2.0 without raster support, you really should rethink that decision, especially if you are a package maintainer (you'll have a lot of pissed off users if you do :)). For PostgreSQL 9.1 extension support, compiling with raster support is ABSOLUTELY required since the postgis extension includes the raster functionality. * Means it currently does or doesn't but may change at release time.