Cuando una herramienta archivada no muere: pgAdmin III y el regreso de la GUI nativa

La popularidad de una herramienta y su soporte oficial son dos cosas distintas. Durante años fue así: pgAdmin III era el cliente GUI estándar para PostgreSQL — una aplicación nativa rápida sobre wxWidgets, sin navegador, sin Node.js, sin una sola línea de JavaScript. Luego llegó PostgreSQL 10 y, con él, una decisión que debía darle al proyecto un nuevo futuro: pgAdmin 4, una reescritura completa en Python/Flask con frontend web, ejecutable como wrapper de escritorio o directamente en el navegador. pgAdmin III fue archivado — oficialmente reemplazado, oficialmente muerto.

Solo que la «versión nueva y mejor» nunca alcanzó la misma popularidad que la antigua. Y esta es una historia que se repite sorprendentemente a menudo en el mundo del código abierto — una nueva generación de una herramienta promete modernización, pero en realidad resuelve sobre todo los problemas de sus autores (mantenimiento multiplataforma, sostenibilidad del código a largo plazo), mientras que el usuario recibe una experiencia más lenta y pesada que nunca pidió.

Este artículo mira el caso concreto de pgAdmin III/4, pero sobre todo dos fenómenos más generales que se esconden detrás: por qué archivar un proyecto no significa su final, y por qué una GUI de escritorio nativa sigue teniendo sentido incluso en una era en la que casi todo lo nuevo se construye como aplicación web.

1. Archivar no significa el final, solo un cambio de dueño

Cuando los mantenedores archivan un proyecto en favor de un sucesor, cuentan con que la comunidad migre. Y la mayoría migra — pero no siempre de buena gana, ni siempre por completo.

pgAdmin 4 trajo consigo una serie de cosas que tenían sentido desde el punto de vista de los autores: código unificado entre plataformas, una interfaz web accesible también de forma remota a través del navegador, mayor facilidad para añadir funciones nuevas sin tener que lidiar con widgets nativos en tres sistemas operativos por separado. Un paso razonable desde el punto de vista de la ingeniería.

Desde el punto de vista del usuario que abre a diario el query tool y espera a que se le renderice un resultado con veinte mil filas, fue un paso en otra dirección. pgAdmin 4 arranca más lento, consume más memoria, y a bastante gente le espantó más de lo que la atrajo de vuelta. Una parte de la comunidad se quedó fiel a la versión antigua a pesar de que ya nadie la mantenía oficialmente — que es exactamente la situación en la que nacen los forks comunitarios.

Encontramos un patrón parecido en otros sitios: una nueva versión «hace avanzar» tecnológicamente al proyecto, pero la UX, la velocidad o la ligereza bajan, y una parte nada desdeñable de los usuarios prefiere quedarse con la versión antigua (sin mantenimiento) antes que pasarse a la nueva (mantenida, pero más pesada).

Una breve línea temporal

Para dar contexto sobre cuánto tiempo lleva desarrollándose esto:

• Finales de los 90/principios de los 2000 — nace PostgreSQL Admin (el predecesor de pgAdmin), que poco a poco se asienta sobre wxWidgets como framework GUI nativo.
• ~2002–2010 — pgAdmin III se convierte en el estándar de facto, crece junto con PostgreSQL y forma parte de los instaladores tanto en Windows como en macOS.
• ~2015–2016 — primeras versiones públicas de pgAdmin 4, en paralelo con pgAdmin III, como «futuro reemplazo».
• 2018 (era de PostgreSQL 10) — pgAdmin III es archivado oficialmente, el desarrollo se concentra exclusivamente en pgAdmin 4.
• Los años siguientes — una parte de la comunidad se queda con pgAdmin III a pesar de la ausencia de soporte oficial, surgen los primeros parches no oficiales para los protocolos más recientes de PostgreSQL.
• Hoy (2026) — el fork comunitario levinsv/pgadmin3 mantiene la herramienta viva en varias plataformas y conserva la compatibilidad hasta PostgreSQL 18. La rama pgadmin3.80.cz, derivada de él, se centra sobre todo en macOS — añade un build nativo para arm64 y completa localizaciones incompletas.

Ocho años después de su archivado, la herramienta de la que la documentación oficial no dice nada sigue viva — solo que no donde la buscaría alguien que se guía únicamente por los canales oficiales.

2. pgAdmin III sigue vivo — ahora también en Apple Silicon

Precisamente por esta razón nació y se sigue desarrollando el fork de pgAdmin III — una rama mantenida por la comunidad del clásico pgAdmin III, centrada en macOS y en un build nativo para Apple Silicon (arm64).

El objetivo del fork no es «reinventar» pgAdmin III, sino mantenerlo utilizable con el PostgreSQL actual y en el hardware actual:

• Soporte para PostgreSQL 12–18 (incluyendo el recién publicado PG18) — el pgAdmin III original solo sabía trabajar con las versiones vigentes en su momento; el fork va completando esta compatibilidad de forma continua.
• Build nativo arm64 para macOS — sin emulación vía Rosetta, a plena velocidad en Macbooks M1/M2/M3/M4.
• Instalación con un solo comando vía Homebrew:

brew install heptau/tap/pgadmin3

• Modo oscuro/claro con cambio automático según la configuración del sistema.
• Iconos preparados para Retina en la barra de herramientas — algo que el pgAdmin III original de 2010 no contemplaba, naturalmente.
• Localización completa a 45 idiomas.
• Funciones que pgAdmin 4 nunca llegó a sustituir del todo: editor SQL con soporte para transformaciones PCRE, query tool con autocompletado a través de joins por clave foránea, comparación de esquemas con integración con Git/GitLab, monitorización del servidor y de wait-events, soporte para SSL/TLS y túneles SSH.

Dicho de otro modo — el fork no busca «parecerse a una app web moderna», sino «seguir siendo una herramienta nativa rápida que funciona con la base de datos de hoy».

Qué hubo que arreglar exactamente

Mantener ejecutable en un sistema actual un proyecto de C++/wxWidgets de veinte años no es solo cuestión de «compilar y ya está». Entre las tareas típicas que exige un fork así están:

• Compatibilidad de protocolo — libpq y los mecanismos de autenticación de PostgreSQL han evolucionado en estos veinte años (SCRAM-SHA-256 en lugar de MD5, nuevas variantes de negociación SSL). Sin actualizarlo, el fork ni siquiera podría conectarse a los servidores más recientes.
• Consultas a catálogos — pgAdmin III consulta directamente los catálogos del sistema (pg_catalog), cuya estructura cambia entre versiones mayores. Una nueva versión del servidor a veces significa que las viejas consultas SQL internas dejan de devolver datos con sentido o directamente fallan.
• Compilación bajo un nuevo SDK — Apple cambia regularmente las API mínimas soportadas y exige actualizaciones a nuevas versiones de Xcode/SDK, lo que en un código C++ antiguo sin ajustes suele traducirse en errores de compilación.
• Empaquetado y distribución — mantener funcionando el tap de Homebrew, el code signing y la notarización para macOS, de modo que la app pueda arrancar tras la instalación sin que Gatekeeper la bloquee con avisos.

Ninguna de estas cosas es en sí misma informática de vanguardia, pero juntas conforman un mantenimiento continuo que antes se hacía en equipo.

Una persona, IA, y los límites de lo que eso aguanta

Mantener un proyecto nativo archivado en 2026 ya no es tan inaccesible como lo habría sido hace unos años. Con ayuda de asistentes de IA, hoy una sola persona puede mantener vivo un fork así compaginándolo con su trabajo a tiempo completo — no necesita invertir todo su tiempo libre en portar código wxWidgets antiguo a nuevas versiones de dependencias, arreglar la compatibilidad con el nuevo protocolo de PostgreSQL o averiguar por qué algo no compila en el SDK actual de macOS. Un trabajo que antes habría requerido un equipo o meses de noches se puede llevar hoy en el orden de horas por semana.

Pero eso tampoco significa que una sola persona con IA a mano sustituya por completo a una comunidad más amplia alrededor del proyecto. Un desarrollador que trabaja principalmente en macOS y no tiene acceso a Windows puede, como mucho, probar el build de Windows en CI y confiar en que funcione — el comportamiento real en un sistema ajeno, los problemas específicos de instalación, el comportamiento tras un antivirus corporativo o en un entorno empresarial simplemente no los conoce por experiencia propia, y la IA no le va a suplir esa experiencia práctica que falta. Cuanta más gente de plataformas y casos de uso distintos use realmente el proyecto y reporte de vuelta, antes se llenarán esos huecos. Por eso una comunidad pequeña pero viva alrededor del fork sigue siendo importante incluso en una época en la que el propio mantenimiento del código ya lo puede llevar un individuo.

3. Por qué querer siquiera una GUI nativa en la era de las aplicaciones web

En los últimos años impera una tendencia clara: las herramientas nuevas se construyen como aplicaciones web, ya sea puramente en el navegador o empaquetadas en Electron como app de «escritorio». Tiene sentido — un solo código para web y escritorio, fácil de compartir entre desarrolladores, sin preocuparse de widgets nativos para Windows/macOS/Linux por separado.

Aun así, la GUI nativa conserva ventajas reales que con esta tendencia se pasan fácilmente por alto:

Velocidad de renderizado

Los widgets nativos (en el caso de pgAdmin III, construidos sobre wxWidgets) se dibujan directamente a través de la API GUI del sistema operativo. Sin DOM, sin reflow, sin ciclo de repintado del navegador, sin capa de JavaScript entre los datos y la pantalla. En un query tool que muestra decenas de miles de filas de resultado, esta diferencia se nota — el scroll es fluido, el filtrado y el ordenado reaccionan al instante.

Lenguaje compilado frente a lenguaje interpretado

Detrás de la diferencia entre pgAdmin III y pgAdmin 4 también está la elección del lenguaje de programación, y merece la pena detenerse en ello porque es una tendencia más general. pgAdmin III está escrito en C++ — se compila directamente a código máquina, y por encima solo corre una fina capa de wxWidgets. pgAdmin 4 está escrito principalmente en Python (backend Flask) con frontend en JavaScript — dos capas de código interpretado, una sobre otra.

El lenguaje interpretado tiene ventajas por las que hoy se elige tan a menudo: desarrollo más rápido, más facilidad para contratar gente, una enorme cantidad de bibliotecas, sin paso de compilación durante el desarrollo. Pero el precio es real — el código interpretado suele ejecutarse en tiempo de ejecución un orden de magnitud más lento que el código C/C++ compilado equivalente, normalmente necesita más memoria para representar los mismos datos (objetos con conteo de referencias y garbage collector en lugar de valores en el stack), y el arranque de la aplicación implica inicializar todo el runtime (intérprete, carga de módulos) en lugar de ejecutar código máquina directamente.

Para un servidor web, donde un solo proceso Python atiende muchas peticiones y donde el I/O de red/base de datos domina de todos modos el tiempo total, esta diferencia suele ser insignificante. Para una aplicación de escritorio, que debe ser inmediatamente responsiva a cada clic del usuario y funcionar de forma eficiente en su máquina local durante todo el día, el mismo compromiso se nota mucho más — y es una de las razones por las que aplicaciones nativas en C++ como pgAdmin III siguen teniendo sentido allí donde eso realmente le importa al usuario.

Tamaño del binario y huella de memoria

Una aplicación nativa suele pesar entre unos pocos y varias decenas de megabytes y no tiene dependencias externas. Una app de Electron tiene que empaquetar todo el runtime de Chromium, lo que habitualmente ronda los 150–200 MB solo para el runtime, más el entorno de Node.js. Eso se nota tanto en el tamaño de la instalación como en el consumo de memoria en tiempo de ejecución — una app que «solo» tiene que mostrar una tabla de datos suele consumir cientos de MB de RAM extra únicamente por llevar dentro un navegador entero.

Ninguna dependencia de la versión de WebView o del runtime de Node

Una aplicación nativa no se rompe por una actualización del componente WebView del sistema o por un cambio de API en Node.js. Corre sobre un framework GUI del sistema operativo estable y con compatibilidad hacia atrás a largo plazo.

El precio a pagar

No es gratis — el desarrollo nativo es más lento, cuesta más encontrar gente que sepa escribir código GUI portable para tres plataformas a la vez, y los widgets «bonitos» modernos (animaciones, componentes personalizados) se hacen bastante peor que en CSS. Por eso muchos proyectos nuevos prefieren la vía web. Pero para una herramienta que debe correr todo el día laboral en segundo plano como cliente de base de datos — donde la velocidad de respuesta y el bajo consumo de recursos importan más que el brillo visual — la GUI nativa sigue siendo una opción razonable.

Comparación orientativa

Las cifras varían según la configuración de la máquina y la versión, pero las diferencias de orden de magnitud entre una aplicación nativa y una app construida sobre Electron/webview se mantienen consistentemente parecidas:

La tabla no sustituye a un benchmark formal — es un resumen de la experiencia que hoy en día vive cualquiera que alterne entre un cliente de BD nativo y su alternativa web/Electron.

Cuándo tiene sentido optar por la variante web

Para ser justos — la GUI nativa no es universalmente «la mejor opción», solo un conjunto distinto de compromisos. Una app web/Electron tiene sentido donde se necesita:

• acceso a la misma herramienta desde varios dispositivos sin instalación (típicamente despliegue en equipo/nube),
• añadir funciones de UI rápidamente, por un solo equipo, para todas las plataformas a la vez,
• integración con un ecosistema web más amplio (SSO, auditoría centralizada, control de acceso a nivel de navegador).

pgAdmin 4 resuelve estas cosas razonablemente bien — solo que no es el mismo encargo que tenía pgAdmin III, y por eso ambos enfoques tienen sentido uno junto al otro.

4. Qué llevarse de todo esto

Archivar un proyecto no significa que haya dejado de existir — solo significa que ha dejado de existir para sus autores. Si detrás de la herramienta hay suficiente gente que quiere seguir usándola, un fork comunitario puede mantener su valor vivo tranquilamente durante años más de lo que planeaba la hoja de ruta original — y con ayuda de la IA, hoy eso lo puede lograr incluso una sola persona. Pero la combinación ideal sigue siendo un mantenedor competente más una comunidad a su alrededor que cubra las plataformas y los casos de uso a los que él solo no llega. Y «más nuevo» no significa automáticamente «mejor para el usuario» — especialmente cuando la nueva versión cambia no solo la tecnología por debajo, sino también lo rápido y lo ligera que responde la herramienta en el uso diario habitual.

Si te topas con una herramienta parecida — antigua, oficialmente abandonada, pero que sigue haciendo bien aquello para lo que fue diseñada — merece la pena comprobar si por casualidad no hay un fork comunitario detrás antes de lanzarse a por su sucesor «oficial». No todo sucesor es automáticamente mejor solo por ser más nuevo y llevar detrás un anuncio de marketing sobre el fin del soporte de la versión antigua.

El fork de pgAdmin III está disponible actualmente también para macOS (arm64), con soporte para PostgreSQL 12–18. Parte del repositorio original levinsv/pgadmin3, donde también encontrarás el build para Windows.

🔗 pgadmin3.80.cz

¿Conoces un caso parecido — una vieja herramienta nativa que sobrevivió a su sucesor oficial gracias a la comunidad? Escríbeme y cuéntamelo.