downgrade PostgreSQL to v13.x

Part of spike to check if all works as expected (bar any tolerable
performance regressions) if we run both apidb and geodb on PostgreSQL
v13, in preparation to moving the database instances in k8s setups to
the Azure database for PostgreSQL Flexible service, which currently
supports PostgreSQL up to version 13.

We have been using PostGIS v3.1 so far, and this PR also bumps up
PostGIS to v3.2 (as this is the version currently supported in the
PostgreSQL v13 Azure managed service).

In theory, functional regressions are not expected with this downgrade
of PostgreSQL, as the key functionality needed for vector tiles is
provided by PostGIS v3.x and we're keeping (and actually bumping up)
this extension's version.

Some performance regressions are expected, instead, with the PostgreSQL
downgrade at least in terms of some lesser parallelization of queries in
some cases: the assumption here is however that we may be trading some
tolerable performance regressions in some cases with the ability to run
the PostgreSQL databases on the Azure managed service, which provide
both functional advantages (backups, restores, other managed
affordances) as well as the ability to potentially use read replicas in
the future to better balance read loads.

README.md

@@ -47,7 +47,7 @@ details.
 
 - [NodeJS](https://nodejs.org/en/) v14.18 and v16.14
 - [Yarn](https://classic.yarnpkg.com/) v1
-- [PostgreSQL](https://www.postgresql.org/) v14
+- [PostgreSQL](https://www.postgresql.org/) v13
 - [Postgis](https://postgis.net/) v3
 - [Redis](https://redis.io/) v6
 - A [Sparkpost](https://www.sparkpost.com/) account

postgresql/apidb.Dockerfile

@@ -1,4 +1,4 @@
-FROM postgres:14.4-alpine3.16
+FROM postgres:13.7-alpine3.16
 LABEL maintainer="hello@vizzuality.com"
 
 CMD ["postgres", "-c", "max_stack_depth=7MB"]

postgresql/geodb.Dockerfile

@@ -1,4 +1,4 @@
-FROM postgis/postgis:14-3.1-alpine
+FROM postgis/postgis:13-3.2-alpine
 LABEL maintainer="hello@vizzuality.com"
 
 CMD ["postgres", "-c", "max_stack_depth=7MB"]