Mantenedor assume extensão pg_mooncake um dia depois de resgatar o vchord no PostgreSQL

Em 5 de novembro de 2026, Ruohang Feng, criador da distribuição Pigsty, publicou no Planet PostgreSQL↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → um relato direto: um dia depois de assumir a manutenção da extensão de busca vetorial vchord, ele repetiu o processo com outra extensão de porte parecido, a pg_mooncake. Ambas escritas em Rust↳Rust7 conteúdosDesmistificando Rust: a linguagem segura e rápida que você precisa conhecerDev (Back & Front) · out 2024Como criar seu primeiro Programa em Rust com Solana PlaygroundDev (Back & Front) · mai 2026Rust no ranking: a segurança de memória perdeu a guerra corporativa?Marketing Tech · abr 2026Ver tudo em Dev (Back & Front) →, ambas abandonadas por motivos de mercado, não por falta de qualidade técnica.

O caso interessa a quem usa PostgreSQL em produção por um motivo simples: extensão não é biblioteca de aplicação que você troca num npm install. Ela mexe com o processo do banco, precisa compilar contra a versão certa do servidor e, quando depende de outra extensão, carrega o risco dessa dependência junto.

O gatilho foi uma aquisição, não um bug

A pg_mooncake é mantida originalmente pela Mooncake Labs, equipe que foi adquirida pela Databricks. Segundo Feng, é um padrão recorrente no open source: quando uma startup é absorvida por uma empresa maior, o repositório que ela deixa para trás raramente volta a receber manutenção ativa. O código não desaparece, mas para de evoluir, e é exatamente isso que aconteceu aqui: o repositório upstream ficou silencioso por mais de um ano.

O problema é que silêncio em código de infraestrutura tem prazo de validade. A pg_mooncake é uma sub-extensão construída sobre a pg_duckdb, que embute o mecanismo analítico do DuckDB dentro do Postgres para viabilizar tabelas colunares e leitura de formatos como Iceberg e Delta Lake direto do banco transacional. Quando o DuckDB lançou a versão 2.0.0 com mudanças internas substanciais, a pg_duckdb precisou de um novo release para acompanhar. E como a pg_mooncake depende diretamente da pg_duckdb, atualizar a extensão pai sem atualizar a filha em lockstep simplesmente quebra a filha.

O playbook de três passos

Feng descreve o processo de retomada como uma sequência repetível, já rodada um dia antes com o vchord:

1. Recuperar a documentação. O site oficial mooncake.dev hoje redireciona direto para a Databricks; a documentação original desapareceu da web viva. Feng recuperou o conteúdo completo, incluindo posts antigos do blog de engenharia, a partir de snapshots do Internet Archive, e republicou tudo.
2. Atualizar o código para a stack atual. A extensão estava congelada na versão 0.2. Feng avançou para a 0.3, atualizou a compatibilidade com a pg_duckdb 1.2 e subiu o framework pgrx (usado para escrever extensões Postgres em Rust) para a versão 0.19.3.
3. Manter em ritmo baixo. Sem a extensão voltar a ter um ciclo de releases constante: só atualizações pontuais quando uma nova versão major do PostgreSQL sair ou quando pgrx e pg_duckdb lançarem novas versões, além de pedidos de recurso razoáveis vindos de usuários reais.

A motivação declarada por Feng não é altruísmo abstrato: ele afirma saber que vários usuários da Pigsty rodam pg_mooncake em produção, e diz que uma das piores coisas que um mantenedor de distribuição pode fazer é entregar uma extensão num release e, no seguinte, simplesmente deixá-la sumir.

Nem sempre o resgate precisa ser feito por um único herói

O próprio texto traz um contraponto que vale reter. O Apache AGE, extensão de banco de dados em grafo para PostgreSQL, estagnou quando seu mantenedor principal perdeu o emprego. Feng chegou a cogitar assumir um fork, como fez agora com vchord e pg_mooncake. Mas, nesse caso, a demanda renovada por workloads de grafo trouxe gente nova para o projeto, e ele se recuperou por conta própria, sem precisar de um fork externo.

A lição aqui não é que todo projeto abandonado tem salvador garantido. É que o destino de uma extensão depende de dois fatores que o desenvolvedor raramente controla: o tamanho da comunidade de usuários reais por trás dela, e a sorte de alguém com conhecimento de internals do Postgres estar disposto a assumir a manutenção quando a comunidade sozinha não é suficiente.

Meu trabalho como mantenedor de uma distribuição é compilar, empacotar e entregar software funcional. Mesmo quando a equipe original segue em frente, a camada de distribuição deve absorver o choque e manter a cadeia de fornecimento de software intacta para quem depende dela.

Ruohang Feng, criador da PigstyMy job as a distribution maintainer is to compile, package, and deliver working software. Even when an upstream team moves on, the distribution layer should absorb the shock and keep the software supply chain intact for downstream users.

O que muda para quem roda extensões em produção

Para o desenvolvedor ou DBA que depende de extensões de terceiros no PostgreSQL, o episódio deixa três pontos práticos, independentemente de usar ou não a Pigsty.

Primeiro, dependência transitiva entre extensões é um risco real de versionamento, não só de aplicação. O mesmo problema que você já enfrenta com package.json ou go.mod existe entre extensões nativas: a pg_mooncake quebrou porque sua dependência direta, a pg_duckdb, teve que acompanhar uma mudança upstream do próprio motor DuckDB. Antes de adotar uma extensão de nicho, vale mapear a árvore de dependências dela, não só a extensão em si.

Segundo, a atividade do repositório upstream é um dado de produção, não um detalhe de curiosidade. Um ano de silêncio num repositório crítico para a sua stack analítica é sinal de alerta antes de a quebra acontecer, especialmente quando a equipe original foi absorvida por uma aquisição, como aconteceu com a Mooncake Labs na Databricks.

Terceiro, distribuições como a Pigsty cumprem aqui um papel equivalente ao de uma distro Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps →: empacotar, testar e garantir compatibilidade entre versões maiores do Postgres para que o usuário final não precise acompanhar cada commit do upstream. Segundo Feng, tanto vchord quanto a pg_mooncake atualizada já estão disponíveis no repositório de extensões da Pigsty, com pacotes pré-compilados para PostgreSQL 14 a 18 em 16 sistemas operacionais, instaláveis via gerenciador de pacotes do sistema ou download direto.

Isso não elimina o risco de depender de um fork mantido por uma pessoa só: se Feng parar de atualizar amanhã, o problema volta. Mas, para quem já tem pg_mooncake rodando em produção, trocar uma dependência silenciosa por um fork ativo e documentado é, na prática, o único caminho razoável até que a Databricks decida (ou não) retomar o projeto original.

Fonte: Planet PostgreSQL