# PostgreSQL 18-Update für Self-Hoster
**URL:** https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194
**Category:** Announcements
**Created:** [3. August 2026 um 04:36 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194 "2026-08-03T04:36:42Z")
**Posts on this page:** 14
**Page:** 5
### Author:  [@Lilly](https://meta.discourse.org/u/Lilly)
#### Post date: [31. August 2026 um 15:46 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/83 "2026-08-31T15:46:27Z")
> [@Ed\_S](#):
>
> Ich würde wahrscheinlich den Wildcard ergänzen, falls noch Reste von Upgrades vorhanden sind.
gute Idee, danke Ed! Ich habe meinen Beitrag aktualisiert. 🙂
---
### Author:  [@LotusJeff](https://meta.discourse.org/u/LotusJeff)
#### Post date: [2. September 2026 um 02:40 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/84 "2026-09-02T02:40:58Z")
Durch diese Änderung habe ich eine allgemeine Reduzierung des Speicherverbrauchs um etwa 4 % festgestellt. Gut gemacht.
---
### Author:  [@AstonJ](https://meta.discourse.org/u/AstonJ)
#### Post date: [6. September 2026 um 02:46 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/85 "2026-09-06T02:46:42Z")
> [@Lilly](#):
>
> Ja, ich habe vor ein paar Wochen Upgrades für Dual-Container auf einem Server durchgeführt (auch auf einem russischen Server). Es gab keinerlei Probleme, aber stelle sicher, dass du vorher genug Festplattenspeicher hast.
Danke Lilly, ich habe das Upgrade gerade durchgeführt und alles scheint in Ordnung zu sein 👍
---
### Author:  [@ecki](https://meta.discourse.org/u/ecki)
#### Post date: [7. September 2026 um 19:23 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/86 "2026-09-07T19:23:12Z")
Dass umgeschriebene Tabellen und Indizes deutlich kompakter werden, ist nichts Ungewöhnliches.
---
### Author:  [@ecki](https://meta.discourse.org/u/ecki)
#### Post date: [7. September 2026 um 19:25 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/87 "2026-09-07T19:25:21Z")
Äh, das liegt im normalen Betrieb von Postgres (je nachdem, ob man vor oder nach VACUUM, Tabellenrebuild usw. hinschaut)
---
### Author:  [@peternlewis](https://meta.discourse.org/u/peternlewis)
#### Post date: [8. September 2026 um 04:53 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/89 "2026-09-08T04:53:57Z")
Seither habe ich nichts vermisst, also soweit ich das beurteilen kann, ist alles in Ordnung.
---
### Author:  [@terminus](https://meta.discourse.org/u/terminus)
#### Post date: [15. September 2026 um 13:46 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/90 "2026-09-15T13:46:25Z")
Ich betreibe Discourse in einem eigenständigen Docker-Container unter `/var/discourse`.
Ich habe versucht, die eingebettete PostgreSQL-Datenbank von Version 15 auf 18 zu aktualisieren. Das Upgrade schien abgeschlossen zu sein, und das aktive Datenverzeichnis meldet nun:
```plaintext
/shared/postgres_data/PG_VERSION
18
```
Der neu aufgebaute Discourse-Container enthält jedoch weiterhin nur die PostgreSQL-15-Binaries:
```plaintext
/usr/lib/postgresql/15/bin/postgres
postgres (PostgreSQL) 15.18
```
Der PostgreSQL-Dienst ist so konfiguriert, dass er ausgeführt wird:
```plaintext
/usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main
```
während das eigentliche Discourse-Datenverzeichnis eingehängt ist unter:
```plaintext
/shared/postgres_data
```
PostgreSQL schlägt folglich mit folgendem Fehler fehl:
```plaintext
FATAL: database files are incompatible with server
DETAIL: The data directory was initialized by PostgreSQL version 18,
which is not compatible with this version 15.18
(Debian 15.18-1.pgdg12+1).
```
Ich verstehe, dass aktuelle Discourse-Docker-Images die PostgreSQL-18-Binaries enthalten sollen. Ich habe `app.yml` geändert, um die PostgreSQL-18-Vorlage zu verwenden, und die App neu aufgebaut, aber der resultierende Container hat weiterhin die PostgreSQL-15-Binaries und das Skript des Dienstes verweist immer noch auf `/etc/postgresql/15/main`.
Der relevante Teil meiner aktuellen Dienstkonfiguration lautet:
```plaintext
HOME=/var/lib/postgresql USER=postgres exec thpoff \
chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert \
/usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main
```
Meine Fragen lauten:
1. Was ist der korrekte Weg, den Discourse-Container so neu aufzubauen oder zu aktualisieren, dass er tatsächlich die PostgreSQL-18-Binaries enthält?
2. Gibt es eine bestimmte Vorlage oder einen bestimmten Image-Tag, der in `app.yml` verwendet werden sollte?
3. Sobald PostgreSQL 18 verfügbar ist, welches unterstützte Verfahren gibt es, es gegen das bestehende `/shared/postgres_data`-Verzeichnis zu starten?
Ich habe das PostgreSQL-18-Datenverzeichnis weder gelöscht noch neu initialisiert. Ich würde den aktualisierten Cluster wiederherstellen, anstatt die alten PostgreSQL-15-Daten wiederherzustellen.
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [15. September 2026 um 14:16 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/91 "2026-09-15T14:16:50Z")
> [@terminus](#):
>
> Ich habe `app.yml` geändert, um die PostgreSQL-18-Vorlage zu verwenden.
basierend auf den Anweisungen im OP scheint das ein unnötiger Schritt gewesen zu sein, es sei denn, ich übersehe etwas?
Einfach nur ein Standard-Install neu aufzubauen, hätte das neueste Image ziehen und die Migration auslösen sollen.
Es sei denn, man wählt bewusst das neueste Image aus, die neuen Binaries waren sicher garantiert? Sehr seltsam …
Bist du sicher, dass du kein Image festgelegt (gepinnt) hast?
---
### Author:  [@terminus](https://meta.discourse.org/u/terminus)
#### Post date: [16. September 2026 um 09:17 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/92 "2026-09-16T09:17:21Z")
> [@merefield](#):
>
> basierend auf den Anweisungen im Eröffnungspost scheint das ein unnötiger Schritt gewesen zu sein, es sei denn, ich übersehe etwas?
>
> Nur das [Standard-Installat](https://meta.discourse.org/t/142537?silent=true) neu aufzubauen, hätte das neueste Image ziehen und die Migration auslösen sollen.
>
> Es sei denn, man wählt bewusst nicht das neueste Image aus – dann waren die neuen Binaries doch garantiert? Sehr seltsam …
>
> Bist du dir sicher, dass du kein Image festgepinnt hast?
Nicht absichtlich? Ich nutze das reguläre Git-Repository und den Branch, und in meiner app.yml steht nichts, was darauf hindeuten würde, dass ich etwas festgepinnt habe. Ich habe nur das postgres-18-Template geändert, um zu sehen, ob das hilft; ja, das war ein unnötiger Schritt, der nicht geholfen hat, also kann ich das wieder zurückändern.
Gibt es Vorschläge, wie ich die neuen Binaries bekomme? Sie sind wirklich nicht da, egal wie oft ich neu baue:
```plaintext
root@hostname-app:/usr/lib/postgresql# ls -la
total 12
drwxr-xr-x 1 root root 4096 May 21 00:47 .
drwxr-xr-x 1 root root 4096 May 21 00:48 ..
drwxr-xr-x 1 root root 4096 May 21 00:47 15
root@hostname-app:/usr/lib/postgresql#
```
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [16. September 2026 um 09:55 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/93 "2026-09-16T09:55:41Z")
> [@terminus](#):
>
> Gibt es Vorschläge, wie man die neuen Binaries bekommt?
Um dir Zeit und Aufwand zu sparen, würde ich vorschlagen, mit deinem letzten Backup einen neuen Server einzurichten – das erspart dir viel Arbeit.
> [@Ihre Discourse-Instanz auf einen anderen Server verschieben](https://meta.discourse.org/t/move-your-discourse-instance-to-a-different-server/15721/1):
>
> bookmark Dies ist eine Anleitung zum Verschieben Ihrer Discourse-Instanz von einem Server auf einen anderen, einschließlich aller Einstellungen und Daten. Diese Anleitung gilt für selbst gehostete Discourse-Instanzen, die Docker verwenden. person_raising_hand Erforderliche Benutzerebene: Systemadministrator warning Dieses Verfahren beinhaltet Änderungen an Domänen und DNS. Stellen Sie sicher, dass Sie Zugriff auf den Quell- und den Zielserver haben. Diese Anleitung führt Sie durch den…
---
### Author:  [@terminus](https://meta.discourse.org/u/terminus)
#### Post date: [16. September 2026 um 12:02 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/94 "2026-09-16T12:02:36Z")
Okay, stimmt schon! Manchmal lohnt es sich nicht, sich mit dem Reparieren aufzuhalten. Danke.
---
### Author:  [@agemo](https://meta.discourse.org/u/agemo)
#### Post date: [22. September 2026 um 14:53 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/95 "2026-09-22T14:53:21Z")
Wenn du das Admin-Panel nicht erreichst, weil dein Discourse-Forum verrückt spielt, wie holst du dir die Datenbank über root@, um sie auf einer neuen Instanz hochzuladen? (Vielleicht gibt es dafür einen anderen Leitfaden)
Oder gibt es einen Befehl, der per Kommandozeile dasselbe bewirkt wie über das Admin-Panel?
---
### Author:  [@agemo](https://meta.discourse.org/u/agemo)
#### Post date: [22. September 2026 um 16:16 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/96 "2026-09-22T16:16:41Z")
Okay, und um auf den Punkt zu kommen: Ich muss die App neu aufbauen, um einen Zertifikatsfehler zu beheben, der offenbar gerade erst aufgetreten ist (keine Änderungen hatten den scheinbaren Fehler vorher verursacht) – der Fehler „Port 443 nicht erreichbar“ taucht auf (der Assistent meldet: „DNS-Verifizierung fehlgeschlagen“) – ich weiß nicht, ob Cloudflare oder DigitalOcean etwas geändert haben, aber auch hier wurde auf meiner Seite nichts verändert. Ich kann die App aber nicht neu aufbauen, vermutlich wegen dieser beiden Fehler, einschließlich des unten stehenden. Letztes Mal war es ein „nicht genügend Speicherplatz“-Fehler. Hast du eine Idee, wie ich den unten stehenden Fehler umgehen kann?
Zusätzlich: Ich habe genau denselben Fehler auch schon vor und nach der Vergrößerung der primären Festplatte bekommen (um den Speicherbedarf von PostgreSQL 15 auf 18 zu berücksichtigen).
```shell
FAILED
--------------------
Pups::ExecError: if [-f /root/install_postgres]; then
/root/install_postgres && rm -f /root/install_postgres
elif [-e /shared/postgres_run/.s.PGSQL.5432]; then
socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1
fi
failed with return #
Location of failure: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/exec_command.rb:138:in 'Pups::ExecCommand#spawn'
exec failed with the params {"tag" => "db", "cmd" => "if [-f /root/install_postgres]; then\n /root/install_postgres && rm -f /root/install_postgres\nelif [-e /shared/postgres_run/.s.PGSQL.5432]; then\n socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1\nfi\n"}
```
---
### Author:  [@agemo](https://meta.discourse.org/u/agemo)
#### Post date: [22. September 2026 um 16:37 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/97 "2026-09-22T16:37:00Z")
Ah, ok, ich habe gefunden, was ich brauche, und zwar von @Lilly, die das schon lange in diesem Thema gepostet hat:
`cd /var/discourse`
`./launcher enter web_only`
`discourse backup`
`exit`
Daraus schließe ich, dass ich damit ein nutzbares DB-Backup erstellen kann, das ich auf einer neuen Discourse-Instanz hochladen und damit alle Probleme umgehen kann.
Liefert dieser Befehl ein vollständiges Backup, also Posts + Uploads/Bilder?
[Vorherige Seite](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194.md?page=4)