Wenn ein archiviertes Tool nicht sterben will: pgAdmin III und die Rückkehr zur nativen GUI

Warum pgAdmin 4 nie zum geliebten Nachfolger von pgAdmin III wurde, wie ein Community-Fork es mit KI-Unterstützung für macOS am Leben hält, und warum native Desktop-GUIs auch 2026 neben Webanwendungen noch ihren Platz haben.

Die Popularität eines Tools und seine offizielle Unterstützung sind zwei verschiedene Dinge. Jahrelang galt: pgAdmin III ist der Standard-GUI-Client für PostgreSQL — eine schnelle native Anwendung auf Basis von wxWidgets, ohne Browser, ohne Node.js, ohne eine einzige Zeile JavaScript. Dann kam PostgreSQL 10, und mit ihm eine Entscheidung, die dem Projekt eine neue Zukunft geben sollte: pgAdmin 4, eine komplette Neuentwicklung in Python/Flask mit Web-Frontend, wahlweise als Desktop-Wrapper oder direkt im Browser gestartet. pgAdmin III wurde archiviert — offiziell ersetzt, offiziell tot.

Nur hat die „neue und bessere Version“ nie dieselbe Popularität erreicht wie die alte. Und das ist eine Geschichte, die sich in der Open-Source-Welt überraschend oft wiederholt — eine neue Generation eines Tools verspricht Modernisierung, löst dabei aber vor allem die Probleme der Autoren (plattformübergreifende Wartung, langfristige Nachhaltigkeit des Codes), während der Nutzer ein langsameres, schwerfälligeres Erlebnis bekommt, das er nie wollte.

Dieser Artikel schaut sich den konkreten Fall pgAdmin III/4 an, vor allem aber zwei allgemeinere Phänomene dahinter: warum die Archivierung eines Projekts nicht sein Ende bedeutet, und warum native Desktop-GUIs auch in einer Ära, in der fast alles Neue als Webanwendung gebaut wird, weiterhin ihre Berechtigung haben.

1. Archivierung bedeutet nicht das Ende, nur einen Besitzerwechsel

Wenn Maintainer ein Projekt zugunsten eines Nachfolgers archivieren, rechnen sie damit, dass die Community mitzieht. Meistens tut sie das auch — aber nicht immer freiwillig, und nicht immer restlos.

pgAdmin 4 brachte eine Reihe von Dingen mit, die aus Sicht der Autoren Sinn ergaben: einheitlicher Code über alle Plattformen hinweg, ein Web-UI, das auch remote über den Browser zugänglich ist, einfacheres Hinzufügen neuer Funktionen, ohne native Widgets auf drei Betriebssystemen einzeln lösen zu müssen. Aus technischer Sicht ein vernünftiger Schritt.

Aus Sicht des Nutzers, der täglich das Query-Tool öffnet und wartet, bis ihm ein Ergebnis mit zwanzigtausend Zeilen gerendert wird, war es ein Schritt in eine andere Richtung. pgAdmin 4 startet langsamer, braucht mehr Arbeitsspeicher und hat viele Leute eher abgeschreckt, als sie zurückzuholen. Ein Teil der Community blieb der alten Version treu, obwohl sie offiziell niemand mehr wartete — genau die Situation, in der Community-Forks entstehen.

Ein ähnliches Muster findet sich auch anderswo: Eine neue Version „bewegt“ ein Projekt technologisch vorwärts, aber UX, Geschwindigkeit oder Leichtigkeit gehen zurück, und ein nicht unerheblicher Teil der Nutzer bleibt lieber bei der alten (ungewarteten) Version, statt zur neuen (gewarteten, aber schwerfälligeren) zu wechseln.

Kurze Zeitlinie

Zum Kontext, wie lange sich diese Entwicklung schon hinzieht:

Acht Jahre nach der Archivierung lebt das Tool, über das die offizielle Dokumentation schweigt, also immer noch — nur eben nicht dort, wo es jemand erwarten würde, der sich nur an offizielle Kanäle hält.

2. pgAdmin III lebt weiter — jetzt auch auf Apple Silicon

Genau aus diesem Grund entstand und entwickelt sich weiter der pgAdmin-III-Fork — ein community-gepflegter Zweig des klassischen pgAdmin III, mit Fokus auf macOS und einem nativen Build für Apple Silicon (arm64).

Ziel des Forks ist nicht, pgAdmin III „neu zu erfinden“, sondern es mit aktuellem PostgreSQL und aktueller Hardware nutzbar zu halten:

brew install heptau/tap/pgadmin3

Anders gesagt — der Fork versucht nicht, „wie eine moderne Web-App auszusehen“, sondern „ein schnelles natives Tool zu bleiben, das mit der heutigen Datenbank funktioniert“.

Was konkret repariert werden musste

Ein zwanzig Jahre altes C++/wxWidgets-Projekt auf einem heutigen System lauffähig zu halten, ist nicht nur eine Frage von „kompilieren und fertig“. Zu den typischen Aufgaben, die so ein Fork erfordert, gehören:

Keine dieser Aufgaben ist für sich genommen aufregende Informatik, aber zusammen ergeben sie eine laufende Wartungsarbeit, die früher im Team erledigt wurde.

Eine Person, KI, und die Grenzen dessen, was das trägt

Ein archiviertes natives Projekt im Jahr 2026 zu pflegen, ist nicht mehr so unerreichbar, wie es vor ein paar Jahren gewesen wäre. Mit Hilfe von KI-Assistenten kann heute auch eine einzelne Person neben ihrem Vollzeitjob so einen Fork am Leben halten — sie muss nicht ihre gesamte Freizeit investieren, um alten wxWidgets-Code auf neue Abhängigkeitsversionen zu portieren, Kompatibilität mit dem neuen PostgreSQL-Protokoll zu reparieren oder herauszufinden, warum etwas auf dem aktuellen macOS-SDK nicht kompiliert. Arbeit, die früher ein Team oder Monate an Abenden gebraucht hätte, lässt sich heute in der Größenordnung von Stunden pro Woche bewältigen.

Das bedeutet aber gleichzeitig nicht, dass eine einzelne Person mit KI an der Hand die breitere Community rund um das Projekt vollständig ersetzt. Ein Entwickler, der primär auf macOS arbeitet und keinen Zugang zu Windows hat, kann den Windows-Build höchstens in CI testen und hoffen, dass er funktioniert — das reale Verhalten auf einem fremden System, spezifische Installationsprobleme, das Verhalten hinter einem Firmen-Antivirus oder in einer Unternehmensumgebung kennt er einfach nicht aus eigener Erfahrung, und KI liefert ihm diese fehlende praktische Erfahrung nicht nach. Je mehr Menschen von unterschiedlichen Plattformen und mit unterschiedlichen Use-Cases das Projekt tatsächlich nutzen und zurückmelden, desto schneller schließen sich diese Lücken. Eine kleinere, aber lebendige Community rund um den Fork bleibt deshalb wichtig, auch wenn die eigentliche Codepflege heute schon eine einzelne Person stemmen kann.

3. Warum überhaupt eine native GUI in Zeiten von Webanwendungen wollen

In den letzten Jahren herrscht ein klarer Trend: Neue Tools werden als Webanwendungen gebaut, sei es rein im Browser oder in Electron verpackt als „Desktop“-App. Das ergibt Sinn — ein Code für Web und Desktop, einfaches Teilen zwischen Entwicklern, keine Sorgen um native Widgets für Windows/macOS/Linux getrennt.

Trotzdem hat native GUI weiterhin reale Vorteile, die man in diesem Trend leicht übersieht:

Rendering-Geschwindigkeit

Native Widgets (im Fall von pgAdmin III auf Basis von wxWidgets) zeichnen direkt über die systemeigene GUI-API des Betriebssystems. Kein DOM, kein Reflow, kein Repaint-Zyklus des Browsers, keine JavaScript-Schicht zwischen Daten und Bildschirm. Beim Query-Tool, das zehntausende Ergebniszeilen anzeigt, ist dieser Unterschied spürbar — Scrollen ist flüssig, Filtern und Sortieren reagieren sofort.

Kompilierte Sprache vs. interpretierte Sprache

Hinter dem Unterschied zwischen pgAdmin III und pgAdmin 4 steckt auch die Wahl der Programmiersprache, und es lohnt sich, dabei innezuhalten, denn es ist ein allgemeinerer Trend. pgAdmin III ist in C++ geschrieben — es wird direkt in Maschinencode kompiliert, darüber liegt nur eine dünne Schicht wxWidgets. pgAdmin 4 ist primär in Python geschrieben (Flask-Backend) mit JavaScript-Frontend — zwei Schichten interpretierten Codes übereinander.

Eine interpretierte Sprache hat Vorteile, wegen derer sie heute so oft gewählt wird: schnellere Entwicklung, einfacheres Anwerben von Leuten, riesige Mengen an Bibliotheken, kein Kompilierungsschritt während der Entwicklung. Der Preis ist aber real — interpretierter Code läuft zur Laufzeit typischerweise um Größenordnungen langsamer als äquivalenter kompilierter C/C++-Code, braucht üblicherweise mehr Speicher zur Repräsentation derselben Daten (Objekte mit Referenzzählung und Garbage Collector statt Werten auf dem Stack), und der Anwendungsstart umfasst die Initialisierung der gesamten Runtime (Interpreter, Laden von Modulen) statt direkt ausgeführten Maschinencode.

Für einen Webserver, bei dem ein Python-Prozess viele Requests bedient und I/O über Netzwerk/Datenbank ohnehin die Gesamtzeit dominiert, ist dieser Unterschied oft vernachlässigbar. Für eine Desktopanwendung, die auf jeden Klick des Nutzers sofort reagieren und den ganzen Tag effizient auf seinem lokalen Rechner laufen soll, macht sich derselbe Kompromiss deutlich spürbarer bemerkbar — und das ist einer der Gründe, warum native C++-Anwendungen wie pgAdmin III dort weiterhin Sinn ergeben, wo es dem Nutzer tatsächlich darauf ankommt.

Binärgröße und Speicherfußabdruck

Native Anwendungen wiegen typischerweise einstellige bis niedrige zweistellige Megabyte und haben keine externen Abhängigkeiten. Eine Electron-App muss die gesamte Chromium-Runtime mitverpacken, was üblicherweise bei 150–200 MB nur für die Runtime selbst liegt, dazu die Node.js-Umgebung. Das schlägt sich sowohl in der Installationsgröße als auch im Speicherverbrauch zur Laufzeit nieder — eine App, die „nur“ eine Datentabelle anzeigen soll, frisst üblicherweise hunderte MB RAM zusätzlich, allein weil sie einen ganzen Browser mit sich trägt.

Keine Abhängigkeit von der WebView- oder Node-Runtime-Version

Native Anwendungen zerbrechen nicht durch ein Update der systemeigenen WebView-Komponente oder eine API-Änderung in Node.js. Sie laufen über einem stabilen, langfristig rückwärtskompatiblen GUI-Framework des Betriebssystems.

Der Preis dafür

Es ist nicht umsonst — native Entwicklung ist langsamer, es ist schwieriger, Leute zu finden, die portablen GUI-Code für drei Plattformen gleichzeitig schreiben können, moderne „hübsche“ Widgets (Animationen, Custom-Komponenten) sind deutlich aufwendiger zu bauen als in CSS. Deshalb schlägt eine Menge neuer Projekte lieber den Web-Weg ein. Aber für ein Tool, das einen ganzen Arbeitstag im Hintergrund als Datenbank-Client laufen soll — wo Reaktionsgeschwindigkeit und niedriger Ressourcenverbrauch wichtiger sind als visueller Glanz — bleibt native GUI eine vernünftige Wahl.

Grober Vergleich

Die Zahlen unterscheiden sich je nach Rechnerkonfiguration und Version, aber die Größenordnung der Unterschiede zwischen einer nativen Anwendung und einer auf Electron/WebView aufgebauten App bleibt konsistent ähnlich:

EigenschaftNative GUI (wxWidgets)Electron/Web-App
Installationsgrößeeinstellige bis niedrige zweistellige MBüblicherweise 150–300 MB (gebündeltes Chromium)
Ruhespeicher (RSS)niedrige zweistellige MBoft hunderte MB selbst für einfache UI
Anwendungsstartpraktisch sofortspürbare Verzögerung (Runtime-Initialisierung)
Rendern einer großen Tabelle (zehntausende Zeilen)flüssig, direkt über System-GUI-APIabhängig von Listen-Virtualisierung in JS, sonst Lag
Offline-Betriebvollständig nativ, keine Abhängigkeitfunktioniert, trägt aber den gesamten Browser mit sich
Entwicklungsgeschwindigkeit neuer Funktionenlangsamer, plattformspezifische Detailsschneller, ein Code für alle Plattformen

Die Tabelle ist kein Ersatz für einen formalen Benchmark — sie ist eine Zusammenfassung der Erfahrung, mit der sich heute und jeden Tag jeder auseinandersetzt, der zwischen einem nativen DB-Client und dessen Web-/Electron-Alternative wechselt.

Wann es umgekehrt Sinn ergibt, zur Web-Variante zu greifen

Der Vollständigkeit halber — native GUI ist nicht universell die „bessere Wahl“, nur ein anderes Set an Kompromissen. Eine Web-/Electron-App ergibt Sinn dort, wo folgendes benötigt wird:

pgAdmin 4 löst diese Dinge vernünftig — nur ist das nicht dieselbe Aufgabenstellung, die pgAdmin III hatte, und deshalb ergeben beide Ansätze nebeneinander Sinn.

4. Was man daraus mitnimmt

Die Archivierung eines Projekts bedeutet nicht, dass es aufgehört hat zu existieren — sie bedeutet nur, dass es aufgehört hat zu existieren für die Autoren. Wenn genug Menschen hinter einem Tool stehen, die es weiter nutzen wollen, kann ein Community-Fork seinen Wert durchaus Jahre länger am Leben halten, als die ursprüngliche Roadmap vorsah — und mit Hilfe von KI schafft das heute auch eine Einzelperson. Die ideale Kombination bleibt aber weiterhin ein geschickter Maintainer plus eine Community um ihn herum, die die Plattformen und Use-Cases abdeckt, die er allein nicht erreicht. Und „neuer“ bedeutet nicht automatisch „besser für den Nutzer“ — besonders wenn die neue Version nicht nur die Technologie unter der Haube ändert, sondern auch, wie schnell und wie leicht das Tool auf die alltägliche Nutzung reagiert.

Wenn Sie auf ein ähnliches Tool stoßen — alt, offiziell aufgegeben, aber bis heute gut darin, wofür es entworfen wurde — lohnt es sich nachzuschauen, ob dahinter nicht zufällig ein Community-Fork steht, bevor Sie zu seinem „offiziellen“ Nachfolger greifen. Nicht jeder Nachfolger ist automatisch besser, nur weil er neuer ist und eine Marketing-Ankündigung über das Support-Ende der alten Version hinter sich hat.

Der pgAdmin-III-Fork ist derzeit auch für macOS (arm64) verfügbar, mit Unterstützung für PostgreSQL 12–18. Er basiert auf dem ursprünglichen Repository levinsv/pgadmin3, wo Sie auch den Build für Windows finden.

🔗 pgadmin3.80.cz

Kennen Sie einen ähnlichen Fall — ein altes natives Tool, das seinen offiziellen Nachfolger dank einer Community überlebt hat? Schreiben Sie mir davon.