Self-hosting

Postgres

Which Postgres version DDM needs, how its fixes arrive, and how to move to a new major version.

DDM runs with Postgres 18 – exactly this major version, from our postgres:18 image. It brings the German dictionary DDM searches with. Only use another major version, a newer one too, once we offer it with an image and describe it here.

Postgres' fixes

Postgres 18's fixes (18.1, 18.2 …) come with every DDM version under the same tag, postgres:18. They need no conversion of the data – a restart with the new image is enough, and DDM is unavailable for a few seconds. Watchtower and Keel leave Postgres out; you fetch them by hand, best with every DDM update:

# Docker Compose
docker compose pull postgres
docker compose up -d postgres

# Kubernetes – ddm.yaml pulls the image anew at every start
kubectl -n ddm rollout restart statefulset/postgres

Moving to a new major version

A new major version (18 → 19) does not read the old one's data: it is backed up and restored into the new one. Only do this once we offer the new version – we tell you with the update. Plan for half an hour in which DDM is unavailable; longer for large databases.

The new version gets a volume of its own. The old one stays untouched – if something goes wrong, you go back to the old version with it. Only once everything runs do you delete it.

With Docker Compose

  1. Stop the apps and back up the database – into a file next to compose.yaml:
    cd /opt/ddm
    docker compose stop cms render-worker client
    docker compose exec -T postgres pg_dump -U ddm -d ddm -Fc > ddm-18.dump
    docker compose stop postgres
    
  2. Change three places in compose.yaml: for the postgres service, the image to …/postgres:19 and the volume from postgres:/var/lib/postgresql to postgres-19:/var/lib/postgresql; under volumes: at the end, add postgres-19:.
  3. Start the new version and restore the backup:
    docker compose up -d postgres
    docker compose exec -T postgres pg_restore -U ddm -d ddm --no-owner < ddm-18.dump
    docker compose up -d
    

With Kubernetes

  1. Stop the apps and back up the database:
    kubectl -n ddm scale deployment cms render-worker client --replicas=0
    kubectl -n ddm exec postgres-0 -- pg_dump -U ddm -d ddm -Fc > ddm-18.dump
    
  2. Change three places in ddm.yaml: for the StatefulSet postgres, the image to …/postgres:19, and the volume's name from postgres to postgres-19 – under volumeMounts and under volumeClaimTemplates.
  3. Create the StatefulSet anew. Its volume is kept – Kubernetes does not delete it with it:
    kubectl -n ddm delete statefulset postgres
    kubectl -n ddm apply -f ddm.yaml
    kubectl -n ddm rollout status statefulset/postgres
    
  4. Restore the backup and start the apps:
    kubectl -n ddm exec -i postgres-0 -- pg_restore -U ddm -d ddm --no-owner < ddm-18.dump
    kubectl -n ddm scale deployment cms render-worker client --replicas=1
    

Afterwards

Check in the CMS that your documents are there and the search finds them. Keep ddm-18.dump and the old volume for a few days, then delete it:

docker volume rm ddm_postgres                    # Docker Compose
kubectl -n ddm delete pvc postgres-postgres-0    # Kubernetes

Back to the old version, if needed: set the three places back and restart – with Kubernetes, as in step 3, with delete statefulset and apply. The old volume has the data from before the move.