senn-techPostgreSQL 14 endet heute: Unser Zensus fand 25 Instanzen, die Container-Liste kannte 21
PostgreSQL 14 verliert heute seinen Support. Das Datum steht nicht in einem Kalender von uns, sondern in der Versionstabelle des Projekts: erste Version 14.0 am 30. September 2021, Enddatum 12. November 2026. Wir haben den Anlass genommen und unseren eigenen Bestand gelesen, ohne Werkzeugliste und ohne Verlass auf Bezeichner, dafür read-only auf jedem System. Ergebnis: 25 Postgres-Instanzen auf 19 Maschinen. Unsere gewohnte Zählung über Container-Namen kennt 21 davon. Die vier anderen sind keine Museumsexemplare, sie laufen nur an Orten, die keine Container-Auflistung nennt.
Stand des Beitrags
Gemessen am 12. November 2026 zwischen 08:30 und 09:05 Uhr mitteleuropäischer Zeit auf unseren eigenen Systemen, read-only über Anmelden und Auslesen, ohne Schreibzugriff, ohne Dienstneustart. Angefragt haben wir 207 Adressen unseres Netzbereichs, geantwortet haben 48. Sechzehn davon brachten keinen Postgres-Prozess hervor, 159 Adressen meldeten sich überhaupt nicht — Tote, Appliance-Systeme ohne Shell und Geräte, die uns nicht hereinlassen. Ob auf einer stummen Adresse eine weitere Instanz läuft, ist damit nicht ausgeschlossen; wir rechnen sie nicht in unsere Zahl hinein. Gezählt wird zuerst pro Prozess, dann zusammengeführt auf Instanzen, definiert über Container-Kennung plus Pfad der Binary. Hostnamen und Adressen nennen wir nicht, weil dieser Beitrag ein Verfahren zeigt und keinen Grundbuchauszug über unsere Gegend.
Was endet am 12. November genau
Die Versionierungspolitik formuliert es in zwei Sätzen: Eine Major-Version wird fünf Jahre nach ihrer Erstveröffentlichung unterstützt, danach erscheint ein letztes Minor Release und die Software gilt danach als unbetreut. Für Major 14 heißt das: Nach dem heutigen Quartalslauf kommt keine weitere Fehlerbehebung mehr für 14.x, weder für den Parser noch für die Replikation noch für einen Decoder.
Der Stand um 09:09 und erneut um 10:17 Uhr: In der Tabelle steht 14.24 als aktuelle Minor, die Dokumentseite zu 14.25 liefert einen Fehlcode, die Nachrichtenseite nennt als letzten Beitrag die Release Candidate 1 zu PostgreSQL 19 vom 15. Oktober. Das Quartalspaket für heute war bei unserer Messung also noch nicht da; ob und unter welcher Nummer es kommt, entscheidet das Release-Team.
Der eigentliche Punkt ist nicht das Alter einer Version, sondern die Zukunft, die ihr fehlt. 14.19, das wir auch gefunden haben, liegt fünf Minor-Releases hinter 14.24 und damit hinter allen Behebungen seit dem Frühjahr. Ab heute kommen für diese Zahl keine mehr dazu.
Vier Zählwege, drei verschiedene Zahlen
Hätten wir nur die Liste der Container genommen, hätten wir 21 Instanzen gemeldet und uns für vollständig gehalten. Der Weg über die Prozess-Tabelle kommt auf 25. Dazwischen liegen vier Startarten, die in keiner Container-Auflistung stehen: eine rootlose Podman-Instanz unter einem Benutzerdienst und drei verteilungseigene Pakete, die ein Host direkt unter systemd startet.
Aufnahmequote der bequemen Methode: 21 von 25, gerechnet 84 Prozent. Das klingt gut und ist als Zahl gefährlich, weil die fehlenden vier nicht gleichverteilt sind. Sie sitzen genau bei den Installationen, die niemand auf dem Schirm hat, wenn er über Container redet.
Die vier Instanzen, die keine Liste kannte
Eine läuft in einem Rootless-Podman. Auf dem Host ist kein Docker-Client installiert, auch der Daemon-Sockel fehlt; abgefragt hat er Podman. In der Prozess-Tabelle erscheint der Dienst über die Benutzer-Dienstverwaltung des Hosts, und weil im Behälter eine eigene Init-Hierarchie mit systemd läuft, sitzt die Datenbank noch eine Ebene tiefer. Diese Instanz meldet 14.24, die letzte Minor von 14: die einzige auf einer veralteten Major, und trotzdem brandaktuell gepatcht.
Drei weitere Instanzen starten als verteilungseigenes Paket auf normalen Servern, erkennbar am Dienst postgresql@17-main.service, mit Paketständen aus dem Fremdpaket-Zweig der Distributoren. Sie laufen auf einem Major, der diese Woche aktuell ist, und fallen durch jede Form von Container-Räson vollständig durch. Welche Datenbankversion ein Host betreut, beantwortet kein Blick in eine Container-Liste, sondern nur der Blick dorthin, wo Prozesse tatsächlich laufen.
Zweimal derselbe Name, zwei Major-Versionen
In jeder Bestandspflege ist der Name der häufigste Schlüssel. Wir haben zwei Behälter mit exakt demselben Namen gefunden, auf verschiedenen Maschinen, mit verschiedenen Ständen: einmal 14.19, einmal 17.8. Eine Zusammenführung über den Namen macht daraus einen Eintrag, und je nach Laune bleibt die alte oder die neue Version übrig. In dieser Lücke verschwindet der Migrationsauftrag für die 14.19.
Der Hypervisor echoet seine Gäste zurück
Auf einem virtualisierten Host standen vier Zeilen, die keine eigenen Instanzen waren: Der Wirt trägt die Prozesse seiner Gäste in der eigenen Tabelle, erkennbar am Weg über die Container-Hierarchie des Gastes. Wer sie mitzählt, meldet doppelte Instanzen auf dem Hypervisor und verliert sie auf den Gästen. Wir rechnen sie deshalb auf den Gast zurück und prüfen jede Zeile gegen die Gästeliste. Bei allen vier war der Nachweis eindeutig: Es sind dieselben Instanzen, die auf ihrem eigenen Gast ebenfalls in der Tabelle standen.
Unser eigenes Zählwerk zählte zuerst zu wenig
Wir haben den Sweep zweimal gefahren, morgens für die Zahl hier, kurz danach zur Kontrolle. Die Kontrolle meldete 27 Instanzen — kein zweiter Bestand, sondern ein zweiter Zählweg. Der eigentliche Fehler steckte im Schlüssel: Wir führen Instanzen über Startart, Binärpfad und Container-Kennung zusammen, und die Kennung schälen wir mit einer Textoperation aus der Hierarchie, die das erste Stück vor dem nächsten Trenner liefert. Beginnt der Pfad mit einem Trenner, ist dieses Stück leer. Drei Instanzen, die ein Host direkt unter systemd startet, teilten sich denselben leeren Schlüssel, zwei Container desselben Bildtyps ebenfalls. Aus 27 Roheinträgen wurden 24 Schlüssel: drei echte Datenbanken waren unsichtbar, genau die, die ohnehin auf keiner Liste stehen.
Die Textoperation haben wir gegen die vollständige Kennung getauscht und gegen die Roheinträge gegengeprüft. Die 25 von 08:30 Uhr bleiben unsere Zahl; die Kontrolle belegt die Mechanik, nicht eine zweite Inventur.
Zwanzig von 25 auf dem aktuellen Stand
Zwanzig Instanzen stehen auf 17.11, der aktuellen Minor der noch unterstützten Major. Drei laufen auf älteren Minor-Ständen derselben Major, das ist Nachziehen, kein Alarm. Zwei stehen auf 14 und sind die einzige echte Migrationsarbeit in diesem Bestand: die eine in einer Fremd-Anwendung, wo der Major vom Hersteller des Pakets kommt, nicht von uns; die andere an einer Anwendung, deren Bild auf 14 gebaut ist. In beiden Fällen entscheidet nicht wir allein über die Datenbankversion.
Was Betreiber daraus mitnehmen
- Bestand über die Prozess-Tabelle aufnehmen, nicht über eine Liste. Eine Instanz existiert, wo ein postmaster-Prozess läuft, unabhängig davon, wer ihn gestartet hat.
- Rootless-Container über die Hierarchie des Benutzerdienstes zählen. Wer nur den Docker-Daemon befragt, übersieht Podman im Benutzerbereich vollständig.
- Den Namen als Schlüssel abschalten. Zwei Behälter dürfen gleich heißen, und unsere Messung zeigt, dass sie es tun, sogar über zwei Major-Versionen hinweg.
- Hypervisor-Echos abziehen, bevor addiert wird. Ein Host mit Containern als Gästen schreibt deren Prozesse in seine eigene Tabelle.
- Nach der Major fragen, nie nach dem Bild-Tagnamen. Ein Bild, das aktuell wirkt, kann eine Major transportieren, die seit heute keinen Patch mehr bekommt.
- Bind-Adresse und Zugangsregeln zusammen lesen. Eine unserer Instanzen lauscht auf allen Adressen, IPv4 und IPv6, und ist nur durch die Zugangsregeln dicht; bei einer anderen meldete die Firewall-Abfrage des Systems „inactive", während die Filtertabelle desselben Kernels 34 Zeilen führte. Eine Abfrage des Firewall-Zustands ist kein Nachweis über die Firewall.
Drei Fragen, die jetzt kommen
Die Antworten stehen oben im Frageblock. Was dort nicht hineingeht: Wir zeigen Verfahren und Zahlen, keine Landkarte unserer Systeme, und wir messen Stände, keine Auslastung. Für die 159 unbeantworteten Adressen gilt die Grenze offen, nicht Null.
Weiterführende Quellen
Alle Angaben zu PostgreSQL aus der Hand des Projekts selbst, gemessen am 12. November 2026 um 09:09 und 10:17 Uhr:
- Versionierungspolitik und Versionstabelle: Enddatum 12. November 2026 für Major 14, aktuelle Minor 14.24, Erstveröffentlichung 30. September 2021.
- Sicherheitsseite des Projekts: Regel für Minor-Releases im Dreimonatstakt und für Außer-Reihe-Freigaben bei kritischen Fehlern.
- Dokumentseite zu 14.25: bei unserer Messung nicht erreichbar, was wir als noch nicht erschienen lesen, nicht als Streit mit dem Projekt.
Für die zwei Speicherorte, an denen unsere Liste blind war, die Dokumentation der Werkzeuge:
- Podman-Handbuch: Betrieb ohne Daemon und im Benutzerbereich, weshalb kein Docker-Client vorhanden sein muss.
- Docker-Daemon-Seite: der Daemon als Sammelstelle für Container-Namen, die unsere erste Schicht war.
- Proxmox-Handbuch zu Linux-Containern: Gäste eines Hypervisors und deren Sichtbarkeit von außen.
Markenzeichen: Die vier Logos in diesem Beitrag sind die Vektordateien der Sammlung Simple Icons, jeweils in der Fassung 13, abgerufen als postgresql.svg, docker.svg, podman.svg und proxmox.svg. Die Sammlung steht unter CC0 1.0 Universal; die Lizenzdatei des Pakets haben wir vor dem Einbau gelesen. Die drei neuen Dateien liegen unverändert bei uns, die Proxmox-Datei kommt aus unserem Bestand, der eine Farbfassung enthält.
Zwei eigene Beiträge, die direkt an diesem Verfahren weiterbauen: Warum wir unsere Laufzeiten selbst protokollieren statt sie aus Bild-Tagnamen zu raten, und unser Flottencheck gegen die Brotli-Lücke in Node.js mit demselben Zensusverfahren gegen eine andere Laufzeit. Für den Blick nach vorn: PostgreSQL 19 Release Candidate 1 mit den Änderungen, in die eine Migration 2027 mündet, und was ein Bild-Vermerk über eine Sandbox entscheidet für alle, die über Podman rechnen wollen, statt ihn nur zu benutzen.
Welches Datum gilt für das Supportende von PostgreSQL 14?+
Die Versionstabelle des Projekts nennt für Major 14 als erste Version den 30. September 2021 und als Enddatum den 12. November 2026. Dazu gehört der Satz aus der Versionierungspolitik, dass eine Major-Version fünf Jahre nach der Erstveröffentlichung unterstützt wird und danach ein letztes Minor Release erscheint, ab dem die Software als unbetreut gilt. Das Enddatum ist also kein Gerücht und keine Kalenderrechnung, sondern eine Angabe des Projekts.
Warum zeigt unser Verzeichnis weniger Postgres-Instanzen als der Prozesszensus?+
Weil die meisten Bestandslisten an Bezeichnern hängen. Eine Aufzählung laufender Container sieht Container, kein Rootless-Podman, der vom Benutzerdienst des Hosts verwaltet wird, und keine Postgres-Instanz, die ein verteilungseigenes Paket unter systemd auf einem normalen Server startet. Bei uns fehlen auf diesem Weg vier von 25 Instanzen, eine davon ausgerechnet die auf 14.24. Die Version war dort brandaktuell, der Speicherort war es, der uns sichtbar macht oder nicht.
Ist eine Instanz auf PostgreSQL 14 nach dem Supportende sofort unsicher?+
Sofort passiert nichts, die Datenbank läuft weiter wie am Tag davor. Was wegfällt, sind künftige Fehlerbehebungen, also auch die Sicherheitsbehebungen, die in drei Monaten auf 17.x erscheinen und an 14.x nie mehr geschrieben werden. Risiko entsteht mit der nächsten Lücke im Decoder, im Parser oder in der Replikation, die dann für diese Instanz unbeantwortet bleibt. Ein Major-Wechsel ist deshalb eine Planungsaufgabe und kein Notfall am Stichtag.