Quando uma ferramenta arquivada não morre: pgAdmin III e o retorno da GUI nativa

Popularidade de uma ferramenta e seu suporte oficial são duas coisas diferentes. Por anos, valeu a regra de que o pgAdmin III era o cliente GUI padrão para PostgreSQL — um aplicativo nativo rápido construído sobre wxWidgets, sem navegador, sem Node.js, sem uma única linha de JavaScript. Depois veio o PostgreSQL 10 e, junto com ele, uma decisão que deveria dar um novo futuro ao projeto: o pgAdmin 4, uma reescrita completa em Python/Flask com frontend web, executado como wrapper desktop ou direto no navegador. O pgAdmin III foi arquivado — oficialmente substituído, oficialmente morto.

Só que a «versão nova e melhor» nunca conquistou a mesma popularidade que a antiga. E essa é uma história que se repete com surpreendente frequência no mundo open source — uma nova geração de ferramenta promete modernização, mas na prática resolve principalmente os problemas de quem a mantém (manutenção multiplataforma, sustentabilidade do código a longo prazo), enquanto o usuário fica com uma experiência mais lenta e pesada, que nunca pediu.

Este artigo olha para o caso específico do pgAdmin III/4, mas sobretudo para dois fenômenos mais gerais escondidos por trás dele: por que o arquivamento de um projeto não significa seu fim, e por que uma GUI desktop nativa ainda faz sentido numa era em que quase tudo o que é novo é construído como aplicação web.

1. Arquivar não é o fim, é só uma troca de dono

Quando os mantenedores arquivam um projeto em favor de um sucessor, contam que a comunidade migre. Na maioria das vezes migra — mas nem sempre de bom grado, e nem sempre por completo.

O pgAdmin 4 trouxe uma série de coisas que faziam sentido do ponto de vista dos autores: código unificado entre plataformas, UI web acessível remotamente pelo navegador, mais facilidade para adicionar novas funcionalidades sem precisar lidar com widgets nativos em três sistemas operacionais separadamente. Do ponto de vista de engenharia, um passo razoável.

Do ponto de vista do usuário que abre o query tool todo dia e espera o resultado com vinte mil linhas renderizar, foi um passo em outra direção. O pgAdmin 4 é mais lento para iniciar, mais pesado em memória, e afastou mais gente do que atraiu de volta. Parte da comunidade permaneceu fiel à versão antiga, mesmo sem mais suporte oficial — exatamente a situação em que nascem forks comunitários.

Um padrão parecido aparece em outros lugares: a nova versão «avança» tecnologicamente o projeto, mas a UX, a velocidade ou a leveza pioram, e uma parcela nada desprezível dos usuários prefere ficar na versão antiga (sem manutenção) a migrar para a nova (mantida, porém mais pesada).

Breve linha do tempo

Para contextualizar há quanto tempo esse desenrolar acontece:

• Fim dos anos 90/início dos 2000 — nasce o PostgreSQL Admin (predecessor do pgAdmin), que aos poucos se firma sobre o wxWidgets como framework de GUI nativo.
• ~2002–2010 — o pgAdmin III se torna o padrão de fato, cresce junto com o PostgreSQL e passa a integrar os instaladores no Windows e no macOS.
• ~2015–2016 — primeiras versões públicas do pgAdmin 4, coexistindo com o pgAdmin III, como «futuro substituto».
• 2018 (era do PostgreSQL 10) — o pgAdmin III é oficialmente arquivado, e o desenvolvimento se concentra exclusivamente no pgAdmin 4.
• Anos seguintes — parte da comunidade permanece no pgAdmin III apesar da ausência de suporte oficial, surgem os primeiros patches não oficiais para protocolos mais novos do PostgreSQL.
• Hoje (2026) — o fork comunitário levinsv/pgadmin3 mantém a ferramenta viva entre plataformas e sustenta compatibilidade até o PostgreSQL 18. A branch pgadmin3.80.cz, derivada dele, foca principalmente no macOS — adiciona build nativo arm64 e aprimora as localizações incompletas.

Oito anos depois de arquivada, a ferramenta sobre a qual a documentação oficial silencia continua viva — só que não onde alguém que segue apenas os canais oficiais esperaria encontrá-la.

2. O pgAdmin III segue vivo — agora também no Apple Silicon

Foi exatamente por esse motivo que nasceu e continua a evoluir o fork do pgAdmin III — uma branch mantida pela comunidade do clássico pgAdmin III, com foco em macOS e build nativo para Apple Silicon (arm64).

O objetivo do fork não é «reinventar» o pgAdmin III, mas mantê-lo utilizável com o PostgreSQL atual e no hardware atual:

• Suporte ao PostgreSQL 12–18 (incluindo o recém-lançado PG18) — o pgAdmin III original só funcionava com as versões então atuais, e o fork vai atualizando essa compatibilidade continuamente.
• Build nativo arm64 para macOS — nenhuma emulação via Rosetta, velocidade plena nos Macbooks M1/M2/M3/M4.
• Instalação com um único comando via Homebrew:

brew install heptau/tap/pgadmin3

• Modo escuro/claro com alternância automática conforme a configuração do sistema.
• Ícones prontos para Retina na barra de ferramentas — algo que o pgAdmin III original, de 2010, naturalmente nunca havia tratado.
• Localização completa em 45 idiomas.
• Funcionalidades que o pgAdmin 4 nunca substituiu completamente: editor SQL com suporte a transformações PCRE, query tool com autocompletar via joins de foreign key, comparação de schemas com integração ao Git/GitLab, monitoramento de servidor e wait events, suporte a SSL/TLS e a túneis SSH.

Em outras palavras — o fork não resolve «como parecer um app web moderno», mas «como continuar sendo uma ferramenta nativa rápida que funciona com o banco de dados de hoje».

O que precisou ser corrigido, na prática

Manter um projeto C++/wxWidgets de vinte anos executável em um sistema atual não é só uma questão de «compilar e pronto». Entre as tarefas típicas exigidas por um fork assim, estão:

• Compatibilidade de protocolo — a libpq e os mecanismos de autenticação do PostgreSQL mudaram muito ao longo desses vinte anos (SCRAM-SHA-256 no lugar do MD5, novas variantes de negociação SSL). Sem atualização, o fork nem conseguiria se conectar a servidores mais novos.
• Consultas a catálogos — o pgAdmin III consulta diretamente os catálogos de sistema (pg_catalog), cuja estrutura muda entre versões major. Uma nova versão do servidor às vezes significa que as antigas consultas SQL internas param de retornar dados coerentes ou simplesmente falham.
• Compilação sob um novo SDK — a Apple muda regularmente a API mínima suportada e exige atualizações para novas versões do Xcode/SDK, o que, em código C++ antigo sem ajustes, costuma resultar em erros de compilação.
• Empacotamento e distribuição — manter um tap do Homebrew funcionando, code signing e notarização para macOS, para que o app sequer abra sem alertas do Gatekeeper depois de instalado.

Nenhuma dessas coisas é ciência de ponta por si só, mas juntas formam uma manutenção contínua que antes era feita em equipe.

Uma pessoa, IA, e os limites do que isso aguenta

Manter um projeto nativo arquivado em 2026 já não é tão inacessível quanto era há alguns anos. Com a ajuda de assistentes de IA, hoje uma única pessoa consegue manter um fork assim vivo ao lado do seu emprego em tempo integral — sem precisar investir todo o tempo livre para portar código wxWidgets antigo para novas versões de dependências, corrigir compatibilidade com o novo protocolo do PostgreSQL ou descobrir por que algo não compila no SDK atual do macOS. Um trabalho que antes exigiria uma equipe ou meses de noites hoje pode ser resolvido em poucas horas por semana.

Isso, no entanto, não significa que uma pessoa com IA à disposição substitua totalmente uma comunidade mais ampla ao redor do projeto. Um desenvolvedor que trabalha principalmente no macOS e não tem acesso ao Windows pode, no máximo, testar o build do Windows no CI e torcer para que funcione — o comportamento real em um sistema diferente, problemas específicos de instalação, o comportamento por trás de um antivírus corporativo ou em um ambiente empresarial, ele simplesmente não conhece por experiência própria, e a IA não fornece essa experiência prática que falta. Quanto mais pessoas de plataformas e casos de uso diferentes realmente usam o projeto e reportam de volta, mais rápido essas lacunas são preenchidas. Por isso, uma comunidade pequena, mas viva, ao redor do fork continua importante mesmo numa época em que a própria manutenção do código já pode ser feita por uma única pessoa.

3. Por que ainda querer uma GUI nativa na era das aplicações web

Nos últimos anos, uma tendência clara se consolidou: novas ferramentas são construídas como aplicações web, seja puramente no navegador, seja empacotadas em Electron como app «desktop». Faz sentido — um único código para web e desktop, compartilhamento fácil entre desenvolvedores, sem se preocupar com widgets nativos para Windows/macOS/Linux separadamente.

Mesmo assim, a GUI nativa ainda tem vantagens reais que são fáceis de ignorar nessa tendência:

Velocidade de renderização

Widgets nativos (no caso do pgAdmin III, construídos sobre wxWidgets) desenham diretamente via API gráfica do sistema operacional. Sem DOM, sem reflow, sem ciclo de repaint do navegador, sem camada JavaScript entre os dados e a tela. No query tool, que exibe dezenas de milhares de linhas de resultado, essa diferença é perceptível — o scroll é fluido, filtrar e ordenar respondem instantaneamente.

Linguagem compilada vs. linguagem interpretada

Por trás da diferença entre o pgAdmin III e o pgAdmin 4 também está a escolha da linguagem de programação, e vale a pena se deter nisso, porque é uma tendência mais ampla. O pgAdmin III é escrito em C++ — compila diretamente para código de máquina, com apenas uma camada fina de wxWidgets rodando sobre ele. O pgAdmin 4 é escrito principalmente em Python (backend Flask) com frontend em JavaScript — duas camadas de código interpretado sobrepostas.

Uma linguagem interpretada tem vantagens que explicam por que é escolhida com tanta frequência hoje: desenvolvimento mais rápido, mais facilidade para contratar pessoas, uma quantidade enorme de bibliotecas, nenhuma etapa de compilação durante o desenvolvimento. Mas o custo é real — código interpretado em execução costuma rodar ordens de grandeza mais devagar que o código C/C++ compilado equivalente, geralmente precisa de mais memória para representar os mesmos dados (objetos com contagem de referências e garbage collector em vez de valores na stack), e o início da aplicação envolve inicializar todo o runtime (interpretador, carregamento de módulos) em vez de simplesmente executar código de máquina direto.

Para um servidor web, onde um único processo Python atende muitas requisições e o I/O de rede/banco de dados já domina o tempo total, essa diferença costuma ser desprezível. Para uma aplicação desktop, que precisa ser instantaneamente responsiva a cada clique do usuário e rodar de forma eficiente na máquina local dele o dia inteiro, o mesmo compromisso se manifesta de forma muito mais sensível — e é uma das razões pelas quais aplicações nativas em C++ como o pgAdmin III ainda fazem sentido onde isso realmente importa para o usuário.

Tamanho do binário e footprint de memória

Aplicações nativas costumam pesar de unidades a dezenas de megabytes e não têm dependências externas. Um app Electron precisa empacotar todo o runtime do Chromium, o que geralmente fica em torno de 150–200 MB só para o runtime, mais o ambiente Node.js. Isso se reflete tanto no tamanho da instalação quanto no consumo de memória em execução — um app que precisa «apenas» exibir uma tabela de dados costuma consumir centenas de MB de RAM a mais só por carregar um navegador inteiro dentro de si.

Nenhuma dependência da versão do WebView ou do runtime Node

Uma aplicação nativa não quebra com a atualização do componente WebView do sistema ou com mudanças na API do Node.js. Ela roda sobre um framework de GUI do sistema operacional estável e com retrocompatibilidade de longo prazo.

O preço a pagar

Não é de graça — o desenvolvimento nativo é mais lento, é mais difícil encontrar pessoas que saibam escrever código de GUI portável para três plataformas ao mesmo tempo, e widgets «bonitos» modernos (animações, componentes customizados) são bem mais difíceis de fazer do que em CSS. Por isso muitos projetos novos preferem o caminho web. Mas para uma ferramenta que precisa rodar o dia inteiro em segundo plano como cliente de banco de dados — onde velocidade de resposta e baixo consumo de recursos importam mais que o brilho visual — a GUI nativa continua sendo uma escolha sensata.

Comparação aproximada

Os números variam conforme a configuração da máquina e a versão, mas as diferenças de ordem de grandeza entre uma aplicação nativa e um app construído sobre Electron/webview permanecem consistentemente parecidas:

A tabela não substitui um benchmark formal — é um resumo da experiência que qualquer pessoa que alterna entre um cliente de banco de dados nativo e sua alternativa web/Electron enfrenta todos os dias.

Quando, ao contrário, faz sentido optar pela variante web

Para ser justo — a GUI nativa não é universalmente «a escolha melhor», apenas um conjunto diferente de compromissos. Um app web/Electron faz sentido quando é preciso:

• acesso à mesma ferramenta a partir de vários dispositivos sem instalação (tipicamente implantação em equipe/na nuvem),
• adicionar funcionalidades de UI rapidamente, por uma única equipe, para todas as plataformas ao mesmo tempo,
• integração com um ecossistema web maior (SSO, auditoria centralizada, controle de acesso no nível do navegador).

O pgAdmin 4 resolve essas questões de forma razoável — só que não é o mesmo escopo de problema que o pgAdmin III tinha, e por isso as duas abordagens fazem sentido lado a lado.

4. O que fica dessa história

Arquivar um projeto não significa que ele deixou de existir — significa apenas que deixou de existir para os autores. Se houver gente suficiente por trás da ferramenta que queira continuar usando-a, um fork comunitário consegue manter seu valor vivo por anos além do que previa o roadmap original — e, com a ajuda da IA, hoje até uma única pessoa dá conta disso. Ainda assim, a combinação ideal continua sendo um mantenedor habilidoso mais uma comunidade ao redor dele, que cobre as plataformas e os casos de uso que ele sozinho não alcançaria. E «mais novo» não significa automaticamente «melhor para o usuário» — especialmente quando a nova versão muda não só a tecnologia por baixo, mas também a rapidez e a leveza com que a ferramenta responde ao uso diário comum.

Se você esbarrar numa ferramenta parecida — antiga, oficialmente abandonada, mas que ainda hoje cumpre bem aquilo para o que foi projetada — vale a pena verificar se não existe um fork comunitário por trás dela antes de recorrer ao seu sucessor «oficial». Nem todo sucessor é automaticamente melhor só por ser mais novo e vir acompanhado de um anúncio de marketing sobre o fim do suporte da versão antiga.

O fork do pgAdmin III está disponível atualmente também para macOS (arm64), com suporte ao PostgreSQL 12–18. Ele parte do repositório original levinsv/pgadmin3, onde você também encontra o build para Windows.

🔗 pgadmin3.80.cz

Conhece um caso parecido — uma ferramenta nativa antiga que sobreviveu ao seu sucessor oficial graças à comunidade? Escreva para mim sobre isso.