DuckLabs se tornará uma subsidiária da AWS e DuckDB continuará sendo MIT sob uma fundação independente. Essa fundação tem um conselho de três assentos, dois são das pessoas que vão para a AWS, e o conselho se nomeia a si mesmo. Essa é a história completa, e quase ninguém está contando.
Status em 27 de agosto de 2026: a operação não está fechada. A Amazon diz que o acordo está sujeito a “customary closing conditions” e que espera fechar “em breve”, sem data. O post dos fundadores fala de início de setembro. Qualquer frase no passado sobre essa aquisição hoje é incorreta.
Em 26 de agosto, Mark Raasveldt e Hannes Mühleisen assinaram um post em duckdb.org anunciando que DuckLabs — a empresa de Amsterdã que construíram em torno do DuckDB, hoje com mais de 30 pessoas — se junta à Amazon Web Services. O comunicado da Amazon é cuidadoso de uma forma que merece crédito: “We are not acquiring the DuckDB open source project, which will remain free and open source under the independent DuckDB Foundation… and available under the MIT license as it does today.” Andy Warfield, o VP da Amazon citado nele, não está exagerando nada. Nenhum termo financeiro foi revelado.
Quero ser preciso com o que estou e não estou argumentando. Não estou dizendo que a AWS vai mudar a licença do DuckDB. Não pode, e disse que não vai. Estou dizendo que a frase que todo mundo está repetindo — a fundação fica com a licença, então não muda nada — está carregando muito mais peso do que pode sustentar, e que o documento que decide quanto peso pode sustentar é público, tem três páginas, e parece que ninguém o leu.
O que a licença MIT realmente protege?
Protege o código que já existe. Cada linha publicada sob MIT fica publicada sob MIT, para sempre, para qualquer um: isso é irrevogável, e por isso o comentário mais votado no Hacker News (1.066 pontos e 308 comentários no momento da redação) está correto: “AWS acquired DuckLabs, NOT DuckDB. The DuckDB source code is still owned by the nonprofit DuckDB Foundation.”
Essa proteção é real e não é pouca coisa. Se tudo der errado, a comunidade faz fork a partir do último commit MIT e segue. Essa saída existe.
O que MIT não protege é tudo aquilo sobre o que você realmente planeja: que features são construídas, em que ordem e com que prioridades; quais extensões são mantidas; se o formato de armazenamento evolui para S3 e Iceberg ou se mantém neutro; com que velocidade seu bug é atendido. As licenças governam cópias. Os roadmaps governam valor, e os roadmaps são governados por pessoas. Ashish Chaturvedi, da HFS Research, o disse ao InfoWorld de forma mais direta do que eu diria: “Developers shouldn’t mistake an unchanged license for an unchanged project. The people writing the bulk of DuckDB’s core code now cash AWS paychecks, and paychecks bend roadmaps.”
E um fork também não é um plano. É um procedimento de recuperação de desastres, e como todo procedimento dessa natureza, seu custo é medido em pessoas que você teria que contratar.
O que é DuckDB e em que se diferencia do SQLite?
Vale a pena definir o assunto, porque dessa diferença depende boa parte da sua exposição.
DuckDB é um banco de dados analítico embarcado: roda dentro do seu processo, sem servidor para administrar, assim como SQLite. A diferença está em para o que cada um foi construído. SQLite é transacional e orientado a linhas: é pensado para ler e escrever registros individuais, que é o que uma aplicação faz. DuckDB é colunar e vetorizado: é pensado para varrer milhões de linhas e agregá-las, que é o que uma consulta analítica faz.
Na prática isso significa que não competem tanto quanto parece. SQLite guarda o estado da sua aplicação; DuckDB responde perguntas sobre seus dados — consultando Parquet, CSV ou tabelas Iceberg diretamente — sem que você tenha que levantar um data warehouse. Junto ao DuckDB, o mesmo time mantém DuckLake (formato de lakehouse) e Quack, e tudo isso é o que o anúncio chama de “Duck Stack”.
Esse detalhe importa para o que segue: a parte embarcada e a parte de lakehouse têm exposições muito distintas diante de um dono estratégico que já tem S3 Tables e Iceberg no portfólio.
Quem governa a Fundação DuckDB?
Aqui está a parte que não vi coberta em lugar nenhum, em nenhum idioma.
A página da fundação diz que é uma organização sem fins lucrativos independente e que “the foundation holds much of the intellectual property (IP) of the project”. Lista três membros do conselho: Hannes Mühleisen, Mark Raasveldt e Peter Boncz. Se financia com doações, com filiação Silver a partir de 10.000 € e Gold a partir de 100.000 €; os apoiadores Gold listados são Voltron Data, MotherDuck e Posit, com Cloudflare como sponsor técnico.
O ato constitutivo da Stichting DuckDB Foundation está publicado como PDF em duckdb.org, e resolve a pergunta. Seu propósito declarado é “to promote the continuity of the DuckDB software, by making and keeping the software generally accessible and available” e administrar os direitos de propriedade intelectual sobre o código e a arquitetura. Depois vêm as cláusulas de governança:
- O conselho se nomeia a si mesmo. “Board members shall be appointed, suspended and dismissed by the Board.” Não há sócios, não há eleitorado, não há assentos por sponsor. A filiação Gold compra um logo, não um voto. Se o conselho chegasse a ficar completamente vazio, CWI INCUBATOR B.V. pode nomear um membro.
- Os assentos são indefinidos e o conselho define seu próprio tamanho. Começou em três; não há mandatos nem renovação.
- O conselho pode reescrever seus próprios estatutos. “The Board is authorised to amend the Articles of Association”, com todos os membros presentes ou representados.
- Remover um membro requer todos os demais. Um membro cessa por “resignation granted by the Board pursuant to a resolution adopted by all other Board members.”
- O único mecanismo diante de conflitos é por decisão pontual. “A Board member shall not participate in the deliberations and decision-making if he has a direct or indirect personal interest in doing so that conflicts with the interests of the Foundation.” Isso é uma regra de abstenção, não uma regra estrutural, e cada membro a avalia por si mesmo.
Agora conte. Dois dos três assentos pertencem aos fundadores que vão dirigir DuckLabs dentro da AWS a partir de setembro. Nada nos anúncios diz que algum deles vai deixar o conselho, e nada no ato o exige: não há nenhuma cláusula sobre emprego, afiliação ou neutralidade de provedor em todo o documento. Então a instituição que tem o IP, e que pode modificar sua própria carta orgânica, muito provavelmente ficará com uma maioria de dois terços empregada pelo comprador.
Não leio como uma manobra. Essa estrutura foi montada em 2021 para um spin-off de pesquisa, e para isso era apropriada. Simplesmente não foi projetada para aguentar um hyperscale, e agora está sendo citada como se estivesse.
O remédio anunciado também não resolve, e os dois anúncios nem mesmo o descrevem igual: duckdb.org fala de um conselho consultivo de stakeholders, enquanto ducklabs.com diz “technical advisory board, so that leading community members can provide their input on the project’s technical direction”. As duas palavras importam. Input não é voto, e um conselho consultivo que não figura nos estatutos pode ser dissolvido pelo órgão ao qual aconselha.
O que aconteceu com OpenSearch e Elasticsearch?
É a pergunta obrigatória, porque é o único precedente onde a AWS é a protagonista. E a resposta é melhor que a reputação da empresa, com um asterisco sobre os prazos.
Em 2021 Elastic mudou Elasticsearch para a licença SSPL. AWS fez um fork e o chamou de OpenSearch, mantendo-o sob Apache 2.0. E no 17 de setembro de 2024 transferiu o projeto para a Linux Foundation como OpenSearch Software Foundation, com um comitê diretor técnico e um board de governança com classes de membros: AWS, SAP e Uber como premier, junto a membros gerais que incluem Aiven, Atlassian, Canonical, DigitalOcean, Graylog e Instaclustr. A página de princípios do projeto se compromete por escrito que “we will not tweak the software so that it runs better for any vendor (including AWS) at the expense of others”. Não há CLA.
Isso é uma cessão de controle real e documentada por parte da AWS, e quem argumentar que a empresa é estruturalmente incapaz de fazê-lo tem que explicar OpenSearch.
Mas veja a forma. Levou três anos, e aconteceu com um projeto que AWS havia criado e controlava completamente, sob pressão competitiva de um fork que ela mesma havia feito. O que significa que o precedente de OpenSearch não é uma garantia de que a governança do DuckDB esteja bem hoje. É a descrição do destino —um board multi-provedor com classes de membros definidas e compromissos de neutralidade por escrito— e uma medição de quanto o viagem levou da última vez.
A distância entre um board de governança da Linux Foundation e três assentos auto-designados não é um detalhe. É exatamente a distância entre a promessa que está sendo feita e a estrutura que a respalda.
O que eu faria agora?
Nada disso justifica arrancar DuckDB de lugar nenhum. É MIT, é embarcado, não há servidor do qual possam desconectá-lo, e o código que você tem hoje é seu para sempre. Essa é uma posição genuinamente sólida —bastante mais sólida do que a que qualquer um teve quando Elastic ou Redis mudaram termos, porque aqui não há licença que possam mudar por baixo.
O que sim justifica é decidir, deliberadamente e este mês, quanto de sua arquitetura depende de decisões que agora pessoas que trabalham para um único provedor de nuvem estão tomando.
- Fixe sua versão e anote qual é. MIT protege o commit que você tem. Essa proteção é apenas real se você sabe qual é esse commit e consegue compilar a partir daí.
- Separe DuckDB de DuckLake em seu registro de riscos. O mecanismo embarcado e o formato de lakehouse têm exposições muito distintas frente a um dono com Iceberg e S3 Tables no portfólio. Trate-os como duas decisões.
- Faça um inventário de suas extensões por mantenedor. O core é a parte mais segura de tudo isso. As extensões com um único mantenedor corporativo são onde um roadmap desviado é notado primeiro.
- Pergunte, por escrito, se os fundadores continuam no board da fundação após o encerramento. É uma pergunta justa, respondível, não custa nada fazê-la, e a resposta diz mais que os três anúncios juntos.
- Observe em o que se torna o advisory board, não que o tenham anunciado. O sinal que há que buscar é uma modificação dos estatutos que crie assentos que AWS não controle. Se em doze meses o advisory board existe mas o board estatutário continua tendo três assentos, você já tem sua resposta.
- Calcule o custo do seu fork uma vez, e depois deixe de pensar nisso. Não para executá-lo: para saber o número. Para a maioria dos times é pequeno, e saber que é pequeno é o que permite adotar com tranquilidade em vez de se cobrir de forma cara.
O resultado mais provável aqui é bom: um time bem financiado entregando mais rápido sob uma licença permissiva, exatamente como foi prometido. Eu simplesmente prefiro sustentar essa expectativa porque revisei a estrutura e não porque um comunicado me tenha dito que a fundação é independente.
Você tem DuckDB em produção hoje? Me interessa sobretudo se está usando embarcado dentro de uma aplicação ou como camada de consulta sobre um lakehouse, porque a exposição a essa operação não é a mesma nos dois casos.