Když archivovaný nástroj nezemře: pgAdmin III a návrat k nativnímu GUI

Popularita nástroje a jeho oficiální podpora jsou dvě různé věci. Roky platilo, že pgAdmin III je ten standardní GUI klient k PostgreSQL — rychlá nativní aplikace nad wxWidgets, bez prohlížeče, bez Node.js, bez jediného řádku JavaScriptu. Pak přišel PostgreSQL 10 a s ním rozhodnutí, které mělo dát projektu novou budoucnost: pgAdmin 4, kompletní přepis na Python/Flask s webovým frontendem, spouštěný buď jako desktop wrapper, nebo přímo v prohlížeči. pgAdmin III byl archivován — oficiálně nahrazen, oficiálně mrtvý.

Jenže „nová a lepší verze“ nikdy nezískala stejnou popularitu jako ta stará. A to je příběh, který se v open-source světě opakuje překvapivě často — nová generace nástroje slibuje modernizaci, ale ve skutečnosti řeší primárně problémy autorů (údržba napříč platformami, dlouhodobá udržitelnost kódu), zatímco uživatel dostane pomalejší, těžkopádnější zážitek, který nikdy nechtěl.

Tenhle článek se dívá na konkrétní případ pgAdmin III/4, ale hlavně na dva obecnější jevy, které se za ním skrývají: proč archivace projektu neznamená jeho konec, a proč má nativní desktopové GUI pořád svoje opodstatnění i v éře, kdy se skoro všechno nové staví jako webová aplikace.

1. Archivace neznamená konec, jen změnu vlastníka

Když maintaineři nějaký projekt archivují ve prospěch nástupce, počítají s tím, že komunita přejde. Většinou přejde — ale ne vždy ochotně, a ne vždy beze zbytku.

pgAdmin 4 přinesl řadu věcí, které dávaly smysl z pohledu autorů: jednotný kód napříč platformami, webové UI dostupné i vzdáleně přes prohlížeč, snazší přidávání nových funkcí bez nutnosti řešit nativní widgety na třech operačních systémech zvlášť. Z inženýrského hlediska rozumný krok.

Z pohledu uživatele, který denně otevírá query tool a čeká, až se mu vykreslí výsledek s dvaceti tisíci řádky, to byl krok jinam. pgAdmin 4 je pomalejší na start, náročnější na paměť, a řadu lidí spíš odradil, než přilákal zpátky. Část komunity zůstala věrná staré verzi navzdory tomu, že ji už nikdo oficiálně neudržoval — což je přesně situace, ve které vznikají komunitní forky.

Podobný vzorec najdeme i jinde: nová verze technologicky „posune“ projekt vpřed, ale UX, rychlost nebo lehkost jdou dolů, a nezanedbatelná část uživatelů raději zůstane u staré (neudržované) verze, než aby přešla na novou (udržovanou, ale těžkopádnější).

Stručná časová osa

Pro kontext, jak dlouho se tenhle vývoj táhne:

• Konec 90. let/začátek 2000 — vzniká PostgreSQL Admin (předchůdce pgAdmin), postupně se ustaluje na wxWidgets jako nativním GUI frameworku.
• ~2002–2010 — pgAdmin III se stává de facto standardem, roste společně s PostgreSQL a je součástí instalátorů na Windows i macOS.
• ~2015–2016 — první veřejné verze pgAdmin 4, souběžně s pgAdmin III, jako „budoucí náhrada“.
• 2018 (PostgreSQL 10 éra) — pgAdmin III je oficiálně archivován, vývoj se soustředí výhradně na pgAdmin 4.
• Následující roky — část komunity zůstává u pgAdmin III navzdory absenci oficiální podpory, vznikají první neoficiální patche pro novější PostgreSQL protokoly.
• Dnes (2026) — komunitní fork levinsv/pgadmin3 drží nástroj naživu napříč platformami a udržuje kompatibilitu až po PostgreSQL 18. Větev pgadmin3.80.cz se z něj soustředí primárně na macOS — přidává nativní arm64 build a dopracovává nekompletní lokalizace.

Osm let po archivaci je tedy nástroj, o kterém oficiální dokumentace mlčí, pořád živý — jen ne tam, kde by ho čekal někdo, kdo se řídí jen oficiálními kanály.

2. pgAdmin III žije dál — teď i na Apple Silicon

Přesně z tohohle důvodu vznikl a dál se rozvíjí pgAdmin III fork — komunitně udržovaná větev klasického pgAdmin III, se zaměřením na macOS a nativní build pro Apple Silicon (arm64).

Cíl forku není „znovu vymyslet“ pgAdmin III, ale udržet ho použitelný s aktuálním PostgreSQL a na aktuálním hardwaru:

• Podpora PostgreSQL 12–18 (včetně čerstvě vydaného PG18) — původní pgAdmin III uměl pracovat jen s tehdy aktuálními verzemi, fork tuto kompatibilitu průběžně dotahuje.
• Nativní arm64 build pro macOS — žádná emulace přes Rosettu, plná rychlost na M1/M2/M3/M4 Macbookách.
• Instalace jedním příkazem přes Homebrew:

brew install heptau/tap/pgadmin3

• Dark/light mode s živým přepínáním podle systémového nastavení.
• Retina-ready ikony v toolbaru — věc, kterou původní pgAdmin III z roku 2010 přirozeně neřešil.
• Plná lokalizace do 45 jazyků.
• Funkce, které pgAdmin 4 nikdy úplně nenahradil: SQL editor s podporou PCRE transformací, query tool s autocompletem přes foreign key joiny, porovnání schémat s integrací na Git/GitLab, monitoring serveru a wait-eventů, podpora SSL/TLS i SSH tunelování.

Jinými slovy — fork neřeší „jak vypadat jako moderní webová appka“, ale „jak zůstat rychlým nativním nástrojem, který funguje s dnešní databází“.

Co konkrétně bylo potřeba opravit

Udržet dvacet let starý C++/wxWidgets projekt spustitelný na dnešním systému není jen otázka „zkompiluj a je to“. Mezi typické úkoly, které takový fork vyžaduje, patří:

• Protokolová kompatibilita — libpq a autentizační mechanismy PostgreSQL se za těch dvacet let posunuly (SCRAM-SHA-256 místo MD5, nové varianty SSL negotiace). Bez aktualizace by se fork k novějším serverům ani nepřipojil.
• Katalogové dotazy — pgAdmin III se ptá přímo na systémové katalogy (pg_catalog), jejichž struktura se mezi major verzemi mění. Nová verze serveru občas znamená, že staré interní SQL dotazy přestanou vracet smysluplná data nebo rovnou selžou.
• Kompilace pod novým SDK — Apple pravidelně mění minimální podporované API a vyžaduje aktualizace na nové Xcode/SDK verze, což u starého C++ kódu bez úprav často znamená kompilační chyby.
• Balíčkování a distribuce — udržet fungující Homebrew tap, code signing a notarizaci pro macOS, aby appka po instalaci vůbec šla spustit bez varování Gatekeeperu.

Žádná z těchto věcí není sama o sobě objevná informatika, ale dohromady tvoří průběžnou údržbu, která se dřív dělala týmově.

Jeden člověk, AI, a hranice toho, co to unese

Udržovat archivovaný nativní projekt v roce 2026 už není tak nedostupné, jako by bylo před pár lety. S pomocí AI asistentů dokáže dnes udržet takový fork naživu i jeden člověk vedle svého plného úvazku — nemusí do toho investovat veškerý volný čas, aby portoval starý wxWidgets kód na nové verze závislostí, opravoval kompatibilitu s novým PostgreSQL protokolem nebo dohledával, proč se něco nekompiluje na aktuálním macOS SDK. Práce, která by dřív vyžadovala tým nebo měsíce večerů, se dá dnes zvládnout v řádu hodin týdně.

To ale zároveň neznamená, že jeden člověk s AI po ruce plně nahradí širší komunitu okolo projektu. Vývojář, který pracuje primárně na macOS a k Windows nemá přístup, může Windows build maximálně otestovat v CI a doufat, že funguje — reálné chování na cizím systému, specifické problémy s instalací, chování za firemním antivirem nebo v podnikovém prostředí prostě nezná z vlastní zkušenosti, a AI mu tuhle chybějící praktickou zkušenost nedodá. Čím víc lidí z různých platforem a use-case projekt reálně používá a hlásí zpět, tím dřív se tyhle mezery zaplní. Menší, ale živá komunita okolo forku proto zůstává důležitá i v době, kdy samotné udržování kódu už dokáže zvládnout jednotlivec.

3. Proč vůbec chtít nativní GUI v době webových aplikací

Poslední roky panuje jasný trend: nové nástroje se staví jako webové aplikace, ať už čistě v prohlížeči, nebo zabalené do Electronu jako „desktop“ appka. Dává to smysl — jeden kód pro web i desktop, snadné sdílení mezi vývojáři, žádné starosti s nativními widgety pro Windows/macOS/Linux zvlášť.

Přesto má nativní GUI pořád reálné výhody, které se v tomhle trendu snadno přehlédnou:

Rychlost vykreslování

Nativní widgety (v případě pgAdmin III postavené na wxWidgets) kreslí přímo přes systémové GUI API operačního systému. Žádný DOM, žádný reflow, žádný repaint cyklus prohlížeče, žádná JavaScriptová vrstva mezi daty a obrazovkou. U query toolu, který zobrazuje desetitisíce řádků výsledku, je tenhle rozdíl citelný — scrollování je plynulé, filtrování a řazení reagují okamžitě.

Kompilovaný jazyk vs. interpretovaný jazyk

Za rozdílem mezi pgAdmin III a pgAdmin 4 stojí i volba programovacího jazyka, a stojí za to se u ní zastavit, protože je to obecnější trend. pgAdmin III je napsaný v C++ — kompiluje se přímo do strojového kódu, běží nad ním jen tenká vrstva wxWidgets. pgAdmin 4 je napsaný primárně v Pythonu (Flask backend) s JavaScriptovým frontendem — dvě vrstvy interpretovaného kódu nad sebou.

Interpretovaný jazyk má svoje výhody, kvůli kterým se dnes tak často volí: rychlejší vývoj, snazší najímání lidí, obrovské množství knihoven, žádný kompilační krok při vývoji. Cena je ale reálná — interpretovaný kód se za běhu typicky vykonává řádově pomaleji než ekvivalentní kompilovaný C/C++ kód, běžně potřebuje víc paměti na reprezentaci stejných dat (objekty s referenčním počítáním a garbage collectorem místo hodnot na stacku) a start aplikace zahrnuje inicializaci celého runtime (interpret, načtení modulů) namísto rovnou spuštěného strojového kódu.

Pro webový server, kde jeden Python proces obsluhuje mnoho requestů a I/O na síť/databázi stejně dominuje celkovému času, je tenhle rozdíl často zanedbatelný. Pro desktopovou aplikaci, která má být okamžitě responzivní na každý klik uživatele a běžet efektivně na jeho lokálním stroji celý den, se stejný kompromis projeví mnohem citelněji — a je to jeden z důvodů, proč nativní C++ aplikace jako pgAdmin III pořád dávají smysl tam, kde na tom uživateli reálně záleží.

Velikost binárky a paměťová stopa

Nativní aplikace typicky váží jednotky až desítky megabajtů a nemá žádné externí závislosti. Electron appka musí zabalit celý Chromium runtime, což se běžně pohybuje kolem 150–200 MB jen na samotný runtime, k tomu Node.js prostředí. To se projeví jak na velikosti instalace, tak na spotřebě paměti za běhu — appka, která má „jen“ zobrazit tabulku dat, běžně žere stovky MB RAM navíc jen kvůli tomu, že v sobě nese celý prohlížeč.

Žádná závislost na verzi WebView nebo Node runtime

Nativní aplikace se nerozbije aktualizací systémového WebView komponenty nebo změnou API v Node.js. Běží nad stabilním, dlouhodobě zpětně kompatibilním GUI frameworkem operačního systému.

Cena za to

Není to zadarmo — nativní vývoj je pomalejší, hůř se hledají lidé, kteří umí psát portable GUI kód pro tři platformy najednou, moderní „hezké“ widgety (animace, custom komponenty) se dělají o dost hůř než v CSS. Proto se spousta nových projektů radši vydává webovou cestou. Ale pro nástroj, který má běžet celý pracovní den na pozadí jako databázový klient — kde rychlost odezvy a nízká spotřeba zdrojů jsou důležitější než vizuální lesk — je nativní GUI pořád rozumná volba.

Orientační srovnání

Čísla se liší podle konfigurace stroje a verze, ale řádové rozdíly mezi nativní aplikací a appkou postavenou nad Electronem/webview zůstávají konzistentně podobné:

Tabulka není náhrada za formální benchmark — je to shrnutí zkušenosti, kterou dnes a denně řeší kdokoliv, kdo přepíná mezi nativním DB klientem a jeho webovou/Electron alternativou.

Kdy naopak dává smysl sáhnout po webové variantě

Pro úplnost — nativní GUI není univerzálně „lepší volba“, jen jiná sada kompromisů. Webová/Electron appka dává smysl tam, kde je potřeba:

• přístup ke stejnému nástroji z více zařízení bez instalace (typicky týmové/cloudové nasazení),
• rychlé přidávání UI funkcí jedním týmem pro všechny platformy najednou,
• integrace do většího webového ekosystému (SSO, centrální audit, řízení přístupu na úrovni prohlížeče).

pgAdmin 4 tyhle věci řeší rozumně — jen to není totéž zadání, jaké mělo pgAdmin III, a proto oba přístupy vedle sebe dávají smysl.

4. Co si z toho odnést

Archivace projektu neznamená, že přestal existovat — znamená jen, že přestal existovat pro autory. Pokud za nástrojem stojí dost lidí, kteří ho chtějí dál používat, komunitní fork dokáže udržet jeho hodnotu naživu klidně o roky déle, než plánovala původní roadmapa — a s pomocí AI to dnes zvládne i jednotlivec. Ideální kombinace je ale pořád jeden šikovný maintainer plus komunita kolem něj, která pokrývá platformy a use-case, na které sám nedosáhne. A „novější“ neznamená automaticky „lepší pro uživatele“ — obzvlášť když nová verze mění nejen technologii pod kapotou, ale i to, jak rychle a jak lehce nástroj reaguje na běžné denní použití.

Pokud narazíte na podobný nástroj — starý, oficiálně opuštěný, ale dodnes dobře dělá to, k čemu byl navržen — stojí za to se podívat, jestli za ním náhodou nestojí komunitní fork dřív, než sáhnete po jeho „oficiálním“ nástupci. Ne každý nástupce je automaticky lepší jen proto, že je novější a má za sebou marketingové oznámení o ukončení podpory té staré verze.

pgAdmin III fork je momentálně dostupný i pro macOS (arm64), s podporou PostgreSQL 12–18. Vychází z původního repozitáře levinsv/pgadmin3, kde najdete i build pro Windows.

🔗 pgadmin3.80.cz

Znáte podobný případ — starý nativní nástroj, který přežil svého oficiálního nástupce díky komunitě? Napište mi o něm.