When an Archived Tool Refuses to Die: pgAdmin III and the Case for Native GUIs

A tool’s popularity and its official support are two different things. For years, pgAdmin III was the standard GUI client for PostgreSQL — a fast native application built on wxWidgets, no browser, no Node.js, not a single line of JavaScript. Then PostgreSQL 10 arrived, along with a decision meant to give the project a new future: pgAdmin 4, a complete rewrite on Python/Flask with a web frontend, launched either as a desktop wrapper or straight in the browser. pgAdmin III was archived — officially replaced, officially dead.

Except the “new and better version” never won the same popularity as the old one. And that’s a story that repeats surprisingly often in the open-source world — a new generation of a tool promises modernization, but in reality mostly solves problems for its authors (cross-platform maintenance, long-term code sustainability), while users get a slower, clunkier experience they never asked for.

This article looks at the specific case of pgAdmin III/4, but mainly at two broader phenomena hiding behind it: why archiving a project doesn’t mean its end, and why native desktop GUIs still make sense in an era when almost everything new gets built as a web app.

1. Archiving Doesn’t Mean the End, Just a Change of Ownership

When maintainers archive a project in favor of a successor, they expect the community to move on. Most of the time it does — but not always willingly, and not always completely.

pgAdmin 4 brought a number of things that made sense from the authors’ perspective: unified code across platforms, a web UI reachable remotely through a browser, easier addition of new features without having to deal with native widgets on three separate operating systems. A reasonable move from an engineering standpoint.

From the perspective of a user who opens the query tool every day and waits for a result set of twenty thousand rows to render, it was a step in the wrong direction. pgAdmin 4 is slower to start, heavier on memory, and put off more people than it won back. Part of the community stayed loyal to the old version despite nobody officially maintaining it anymore — which is exactly the situation in which community forks are born.

You find a similar pattern elsewhere: a new version technologically “advances” a project, but UX, speed, or lightness go down, and a non-trivial share of users would rather stick with the old (unmaintained) version than move to the new (maintained, but clunkier) one.

A Brief Timeline

For context, here’s how long this has been playing out:

• Late 1990 s/early 2000 s — PostgreSQL Admin (pgAdmin’s predecessor) emerges, gradually settling on wxWidgets as its native GUI framework.
• ~2002–2010 — pgAdmin III becomes the de facto standard, grows alongside PostgreSQL, and ships as part of installers on Windows and macOS alike.
• ~2015–2016 — first public versions of pgAdmin 4 appear, alongside pgAdmin III, billed as the “future replacement.”
• 2018 (PostgreSQL 10 era) — pgAdmin III is officially archived, development focuses exclusively on pgAdmin 4.
• The following years — part of the community stays on pgAdmin III despite the lack of official support; the first unofficial patches for newer PostgreSQL protocols appear.
• Today (2026) — the community fork levinsv/pgadmin3 keeps the tool alive across platforms and maintains compatibility all the way up to PostgreSQL 18. A branch, pgadmin3.80.cz, focuses primarily on macOS — adding a native arm64 build and finishing off incomplete localizations.

Eight years after being archived, the tool the official documentation stays silent about is still alive — just not where anyone relying solely on official channels would expect to find it.

2. pgAdmin III Lives On — Now on Apple Silicon Too

That’s exactly why the pgAdmin III fork was created and continues to be developed — a community-maintained branch of the classic pgAdmin III, focused on macOS and a native build for Apple Silicon (arm64).

The fork’s goal isn’t to “reinvent” pgAdmin III, but to keep it usable with current PostgreSQL and on current hardware:

• Support for PostgreSQL 12–18 (including the freshly released PG18) — the original pgAdmin III only worked with whatever versions were current at the time; the fork keeps extending that compatibility.
• Native arm64 build for macOS — no Rosetta emulation, full speed on M1/M2/M3/M4 Macs.
• One-command installation via Homebrew:

brew install heptau/tap/pgadmin3

• Dark/light mode with live switching based on system settings.
• Retina-ready toolbar icons — something the original 2010-era pgAdmin III naturally never addressed.
• Full localization into 45 languages.
• Features pgAdmin 4 never fully replaced: an SQL editor with PCRE transformation support, a query tool with autocomplete across foreign key joins, schema comparison with Git/GitLab integration, server and wait-event monitoring, and support for SSL/TLS and SSH tunneling.

In other words — the fork isn’t concerned with “looking like a modern web app,” but with “staying a fast native tool that works with today’s database.”

What Actually Needed Fixing

Keeping a twenty-year-old C++/wxWidgets project runnable on today’s systems isn’t just a matter of “compile it and you’re done.” Typical tasks a fork like this requires include:

• Protocol compatibility — libpq and PostgreSQL’s authentication mechanisms have moved on over those twenty years (SCRAM-SHA-256 instead of MD5, new SSL negotiation variants). Without updates, the fork wouldn’t even connect to newer servers.
• Catalog queries — pgAdmin III queries the system catalogs (pg_catalog) directly, and their structure changes between major versions. A new server version can mean old internal SQL queries stop returning meaningful data or fail outright.
• Compiling under a new SDK — Apple regularly changes the minimum supported API and requires updates to newer Xcode/SDK versions, which often means compilation errors for old C++ code left untouched.
• Packaging and distribution — keeping a working Homebrew tap, code signing, and notarization for macOS so the app can even launch after installation without Gatekeeper warnings.

None of these things is groundbreaking computer science on its own, but together they add up to ongoing maintenance that used to be done by a team.

One Person, AI, and the Limits of What That Can Carry

Maintaining an archived native project in 2026 isn’t as out of reach as it would have been a few years ago. With the help of AI assistants, a single person can now keep a fork like this alive alongside a full-time job — they don’t have to pour every free hour into porting old wxWidgets code to new dependency versions, fixing compatibility with the new PostgreSQL protocol, or hunting down why something won’t compile on the current macOS SDK. Work that used to require a team or months of evenings can now be handled in a matter of hours per week.

That doesn’t mean, though, that one person with AI at hand fully replaces a broader community around the project. A developer who works primarily on macOS and has no access to Windows can at best test the Windows build in CI and hope it works — the real-world behavior on a foreign system, specific installation issues, behavior behind a corporate antivirus or inside an enterprise environment simply aren’t things they know from experience, and AI won’t supply that missing practical knowledge. The more people from different platforms and use cases actually use the project and report back, the sooner those gaps get filled. A small but alive community around the fork therefore stays important even at a time when a single individual can already handle the code maintenance itself.

3. Why Even Want a Native GUI in an Age of Web Apps

The last few years have shown a clear trend: new tools get built as web applications, whether purely in the browser or wrapped in Electron as a “desktop” app. That makes sense — one codebase for both web and desktop, easy sharing among developers, no worrying about native widgets for Windows/macOS/Linux separately.

Even so, native GUIs still have real advantages that are easy to overlook in this trend.

Rendering speed

Native widgets (in pgAdmin III’s case, built on wxWidgets) draw directly through the operating system’s GUI API. No DOM, no reflow, no browser repaint cycle, no JavaScript layer between the data and the screen. For a query tool displaying tens of thousands of result rows, that difference is noticeable — scrolling is smooth, filtering and sorting respond instantly.

Compiled language vs. interpreted language

Behind the difference between pgAdmin III and pgAdmin 4 also lies a choice of programming language, and it’s worth stopping on because it’s a broader trend. pgAdmin III is written in C++ — it compiles directly to machine code, with only a thin wxWidgets layer sitting on top. pgAdmin 4 is written primarily in Python (Flask backend) with a JavaScript frontend — two layers of interpreted code stacked on top of each other.

Interpreted languages have advantages that explain why they’re chosen so often today: faster development, easier hiring, a huge library ecosystem, no compilation step during development. But the cost is real — interpreted code typically executes an order of magnitude slower at runtime than equivalent compiled C/C++ code, usually needs more memory to represent the same data (reference-counted objects and a garbage collector instead of stack values), and application startup involves initializing an entire runtime (interpreter, module loading) instead of jumping straight into machine code.

For a web server, where a single Python process handles many requests and network/database I/O already dominates total time, this difference is often negligible. For a desktop application that’s supposed to respond instantly to every user click and run efficiently on their local machine all day long, the same trade-off shows up much more noticeably — and it’s one of the reasons native C++ applications like pgAdmin III still make sense wherever it genuinely matters to the user.

Binary size and memory footprint

Native applications typically weigh a few to a few dozen megabytes and carry no external dependencies. An Electron app has to bundle the entire Chromium runtime, which commonly runs around 150–200 MB for the runtime alone, plus a Node.js environment on top. That shows up both in install size and in runtime memory usage — an app that “just” needs to show a data table routinely eats hundreds of extra MB of RAM simply because it’s carrying an entire browser inside it.

No dependency on WebView or Node runtime versions

A native application doesn’t break because a system WebView component got updated or a Node.js API changed. It runs on top of a stable, long-term backward-compatible GUI framework provided by the operating system.

The price you pay

It isn’t free — native development is slower, it’s harder to find people who can write portable GUI code for three platforms at once, and modern “pretty” widgets (animations, custom components) are considerably harder to build than in CSS. That’s why so many new projects would rather go the web route. But for a tool meant to run in the background all day as a database client — where response speed and low resource usage matter more than visual polish — a native GUI is still a reasonable choice.

A Rough Comparison

The numbers vary depending on machine configuration and version, but the order-of-magnitude differences between a native application and one built on Electron/webview stay consistently similar:

The table isn’t a substitute for a formal benchmark — it’s a summary of the experience anyone switching between a native DB client and its web/Electron alternative runs into every day.

When Reaching for the Web Variant Makes Sense Instead

For completeness — a native GUI isn’t a universally “better choice,” just a different set of trade-offs. A web/Electron app makes sense where you need:

• access to the same tool from multiple devices without installation (typically team/cloud deployments),
• fast addition of UI features by a single team across all platforms at once,
• integration into a larger web ecosystem (SSO, centralized auditing, browser-level access control).

pgAdmin 4 handles these things reasonably well — it just isn’t solving the same brief pgAdmin III had, which is why both approaches make sense side by side.

4. What to Take Away From This

Archiving a project doesn’t mean it stops existing — it just means it stops existing for its authors. If enough people care about a tool to keep using it, a community fork can keep its value alive for years longer than the original roadmap ever planned — and with AI’s help, a single person can now pull that off. But the ideal combination is still one capable maintainer plus a community around them that covers the platforms and use cases they can’t reach on their own. And “newer” doesn’t automatically mean “better for the user” — especially when a new version changes not just the technology under the hood, but also how fast and how lightly the tool responds to everyday use.

If you run into a similar tool — old, officially abandoned, but still doing well what it was designed to do — it’s worth checking whether a community fork happens to stand behind it before reaching for its “official” successor. Not every successor is automatically better just because it’s newer and comes with a marketing announcement ending support for the old version.

The pgAdmin III fork is currently available for macOS (arm64) as well, with support for PostgreSQL 12–18. It’s based on the original levinsv/pgadmin3 repository, where you’ll also find the Windows build.

🔗 pgadmin3.80.cz

Know a similar case — an old native tool that outlived its official successor thanks to its community? Write and tell me about it.