A aposta da AWS em uma DuckDB aberta com a compra da DuckLabs

A Amazon concordou em comprar a DuckLabs, empresa responsável pela DuckDB, sem adquirir acesso exclusivo ao mecanismo. A DuckDB continuará sendo um software livre e de código aberto — uma limitação que parece cada vez menos uma concessão à medida que agentes de programação reduzem o custo de montar aplicações de dados.

A AWS está comprando alcance, não escassez

O valor da aquisição da DuckLabs pela Amazon não foi divulgado. A DuckDB continuará sob a DuckDB Foundation, enquanto a DuckLabs afirma que a integração à AWS levará mais recursos e alcance à DuckDB, à DuckLake e ao protocolo Quack.

Quem compra uma empresa de software pode restringir um ativo e cobrar pelo acesso. A AWS, por sua vez, manterá a DuckDB disponível para implantação em diferentes ambientes, ao mesmo tempo que conquista uma posição privilegiada junto às pessoas, integrações, serviços de suporte e práticas operacionais que transformam um mecanismo em um sistema empresarial.

A AWS precisa dessa portabilidade. Desenvolvedores podem incorporar a DuckDB sem antes vincular uma aplicação à arquitetura de uma única nuvem, o que permite que o mecanismo se torne um componente padrão já nas etapas iniciais do desenvolvimento. Fechá-lo protegeria a exclusividade do código-fonte, mas prejudicaria justamente a distribuição que a Amazon está adquirindo.

Quem desenvolve produtos já usa a DuckDB dessa forma. Um desenvolvedor que trabalha com o Quack descreveu a DuckDB como o principal mecanismo de armazenamento previsto para uma plataforma. Outro afirmou que o Hex não seria possível sem ela. Eles não estavam contratando um banco de dados centralizado, mas escolhendo um componente que se encaixava no que já construíam.

Em September 2023, a MotherDuck captou $52.5 million em uma rodada Série B para comercializar uma plataforma baseada na DuckDB, com avaliação de $400 million após o aporte. Quase três anos depois, a AWS concordou em adquirir a empresa responsável pelo mecanismo e se comprometeu a mantê-lo aberto. Nos dois negócios, a camada comercial fica ao redor do núcleo, e não dentro de sua licença.

Esse é um modelo de distribuição administrada de código aberto: facilitar a adoção da base tecnológica e, depois, disputar a operação ao redor dela. O mesmo incentivo aparece nas estratégias de modelos com pesos abertos, nas quais o amplo acesso pode atrair desenvolvedores para a infraestrutura e os serviços que o distribuidor ainda controla. Nos dois casos, o código é a estrada que leva ao pedágio, não o pedágio em si.

Agentes tornam o mecanismo mais útil — e complicam a governança

A Apple adicionou suporte a Claude Agent, Codex e MCP no Xcode 26.3, levando a programação por agentes a uma ferramenta de desenvolvimento amplamente usada. Separadamente, o Google apresentou uma plataforma para administrar frotas de agentes empresariais. Uma iniciativa reduz o atrito na criação de programas; a outra enfrenta a complexidade que surge quando esses programas começam a atuar em vários sistemas.

Apple e Google tratam de lados opostos da mesma transformação. Quando o ambiente de desenvolvimento se torna um espaço de trabalho operado por agentes, componentes reutilizáveis ganham valor porque um agente pode acioná-los, combiná-los e modificá-los sem obrigar cada equipe a reconstruir a mesma funcionalidade. As equipes podem adotar um pequeno mecanismo de processamento antes de conseguirem justificar o compromisso com uma plataforma totalmente centralizada.

Agentes de programação fazem mais do que produzir código com rapidez; eles barateiam a recombinação de recursos. Podem reunir acesso, transformação, armazenamento e recuperação de dados a partir de funções encapsuladas de forma independente. Um mecanismo acessível passa a caber em mais lugares: dentro de uma aplicação, ao lado de um conjunto de dados local ou por trás de uma ferramenta acionada por um agente conforme a tarefa.

Cada nova aplicação criada por agentes pode abrir outro caminho até credenciais, dados empresariais, capacidade de processamento em produção e recursos compartilhados. Um mecanismo local cuida do processamento, mas não de identidade, políticas, compartilhamento seguro, monitoramento, implantação ou suporte. À medida que os agentes tornam viável criar mais aplicações, as empresas precisam reforçar os controles ao redor delas.

A AWS pode lucrar com o que a DuckDB não oferece

Um mecanismo aberto de consultas não pode cobrar pela escassez de acesso como um produto fechado. Ainda assim, ele pode ampliar a demanda por tudo o que cerca uma consulta: processamento elástico em picos de uso, armazenamento e transferência, implantação administrada, controles de identidade, permissões detalhadas e suporte quando um componente incorporado se transforma em infraestrutura de produção.

A AWS pode capturar margem na camada imediatamente acima do mecanismo. Provedores de nuvem já vendem processamento com cobrança por uso, adequada a uma demanda variável. Armazéns de dados e plataformas que combinam lagos e armazéns acrescentam compartilhamento entre vários usuários e permissões capazes de filtrar o acesso por linha, coluna e nível de sensibilidade. Esses serviços continuam escassos mesmo quando o código de processamento está disponível gratuitamente.

O compromisso de cinco anos da Snowflake com a AWS, que abrange infraestrutura de nuvem e circuitos integrados, mostra a dimensão desse mercado ao redor do produto. A AWS não precisa ser dona do software da Snowflake para lucrar com seu crescimento; ela fornece a capacidade que sustenta a plataforma. A DuckDB abre outro caminho ao se disseminar entre desenvolvedores antes que as aplicações precisem de um ambiente de produção.

Snowflake e Databricks mostram onde o valor empresarial ainda se acumula. A Snowflake registrou receita trimestral de $1.39 billion, alta de 33% em relação ao ano anterior. A Databricks captou $5 billion com avaliação de $190 billion. O processamento aberto e incorporado não está eliminando as plataformas centralizadas de dados; está obrigando-as a buscar margem em outras camadas.

Para a AWS, a vantagem está na implantação. A DuckDB pode continuar portátil enquanto o uso administrado se torna mais simples na AWS, onde processamento, identidade, políticas, compartilhamento e suporte já estão integrados. Conveniência e integração geram uma dependência mais fraca do que a exclusão, mas oferecem um alcance de distribuição maior.

A centralização persiste porque a governança não pode se fragmentar

As empresas não precisam escolher entre mecanismos incorporados e armazéns de dados ou plataformas que combinam lagos e armazéns. Um componente da aplicação pode executar uma tarefa delimitada perto do desenvolvedor ou do agente, enquanto uma plataforma central preserva o contexto compartilhado, as permissões, a operação em grande escala e as políticas que precisam permanecer uniformes entre as aplicações.

As empresas centralizam a governança porque credenciais e acesso a dados compartilhados podem produzir impactos de grande alcance. O caso de invasões relacionado à Snowflake envolveu dados roubados de mais de 165 empresas. Isso não prova que a centralização causou as violações nem que uma arquitetura distribuída teria evitado o problema. O episódio mostra por que a governança se torna decisiva quando muitas aplicações e agentes conseguem acessar os mesmos dados empresariais.

Uma atividade maior de agentes tampouco garante resultados econômicos atraentes na nuvem. A Databricks afirmou que o aumento no uso de agentes de IA elevava os custos e reduzia as margens, mesmo com a receita anualizada crescendo mais de 80% em relação ao ano anterior, para $6.9 billion. Agentes podem elevar o consumo de infraestrutura mais rapidamente do que as plataformas melhoram a rentabilidade por unidade. Uma camada de controle só justifica sua existência se conseguir administrar essa demanda sem permitir que os custos de processamento absorvam o valor gerado.

Para uma empresa compradora, isso significa aprovar funcionalidades baseadas na DuckDB sem deixar cada equipe criar seu próprio perímetro de segurança. As equipes podem executar tarefas delimitadas junto à aplicação, enquanto a plataforma central mantém identidades, permissões, conjuntos de dados compartilhados e limites de gastos.

A portabilidade determinará se a AWS conquistará o ponto de controle

O anúncio da DuckLabs é um sinal inicial, não uma prova de que esse modelo venceu. A AWS ainda não detalhou um produto administrado baseado na DuckDB, um modelo de preços ou um plano de integração. Seu compromisso com o código aberto preserva um caminho para a distribuição com governança, mas ainda não explica como a AWS pretende ganhar dinheiro.

A DuckDB precisa manter sua credibilidade em diferentes ambientes após a aquisição. Se os desenvolvedores continuarem tratando-a como um componente fundamental capaz de funcionar independentemente da AWS, seu alcance de adoção permanecerá amplo. A AWS poderá então disputar a preferência ao tornar mais simples a operação administrada ao redor do mecanismo, sem convertê-lo em uma dependência de sua nuvem.

Se, ao contrário, a DuckDB se tornar principalmente um recurso integrado à AWS, o negócio seguirá o padrão tradicional da computação em nuvem: adquirir uma tecnologia útil e trazer suas cargas de trabalho para uma rede proprietária de geração de valor. O mecanismo pode continuar aberto na licença e, ainda assim, ter uma distribuição prática mais restrita. Código aberto, por si só, não garante liberdade de circulação.

A MotherDuck mostrou um caminho comercial: vender uma plataforma acima da DuckDB e manter o núcleo fora do controle proprietário. A AWS tenta uma versão mais abrangente, que inclui processamento, identidade, compartilhamento e suporte. Os desenvolvedores avaliarão essa gestão pelos ambientes em que a DuckDB funciona com facilidade, não apenas pelo texto da licença.

A Amazon pode comprar a DuckLabs sem fechar a DuckDB porque é justamente a abertura que leva o mecanismo a mais aplicações. À medida que os agentes reduzem os custos de desenvolvimento, a AWS ganha força ao facilitar identidade, políticas, suporte e processamento ao redor do mecanismo. O paradoxo da aquisição também explica sua lógica: o ponto de controle da AWS depende de a DuckDB continuar livre para funcionar em outros ambientes.