O que a AWS anunciou

Em 5 de agosto de 2026, a AWS anunciou que a Amazon DynamoDB passa a tratar a pesquisa vetorial de forma nativa, sem necessidade de construir ou manter um índice vetorial separado. A empresa refere uma latência de milissegundos de um só dígito com uma recall superior a 99 por cento, escalável até biliões de vetores. A SiliconANGLE e a InfoWorld noticiaram o anúncio de forma independente no mesmo dia, descrevendo-o como uma capacidade nativa e não como um serviço acoplado.

O mecanismo é simples: a pesquisa vetorial passa a correr na mesma tabela que já guarda os dados primários da aplicação. Deixa de haver uma segunda base de dados para aprovisionar, um passo de exportação e importação, ou um pipeline que tenha de manter um índice vetorial separado sincronizado com as alterações na tabela de origem.

É precisamente este último ponto que merece atenção. Eliminar o pipeline de sincronização elimina o atraso entre a atualização de um registo e o seu aparecimento nos resultados de pesquisa, e elimina toda uma classe de erros que surge quando dois repositórios de dados se desalinham entre si.

A categoria de fornecedores ameaçada

Ao longo dos últimos dois a três anos, acrescentar pesquisa semântica ou geração aumentada por recuperação (RAG) a um produto significou quase sempre adotar uma segunda base de dados, construída propositadamente para vetores, ao lado da base de dados que já guardava os dados reais. A Pinecone, a Weaviate e a Milvus construíram os seus negócios exatamente nesse espaço, e as extensões do Postgres cobriam a mesma necessidade para equipas que queriam manter-se num único motor.

Este padrão tornou-se quase uma rubrica fixa nos planos de projetos de IA: orçamento para um fornecedor de base de dados vetorial, orçamento de tempo de engenharia para um pipeline de sincronização, e orçamento para uma segunda revisão de segurança porque os dados dos utilizadores passam agora por um segundo subcontratante. Nenhum destes custos era exótico, mas todos eram dados como necessários.

O que a AWS lançou a 5 de agosto não apaga esta categoria de fornecedores, mas retira-lhe a justificação automática num caso grande e comum: qualquer equipa cujos dados primários da aplicação já vivem na DynamoDB. Para esse grupo, o argumento a favor de uma base de dados vetorial separada tem agora de ser demonstrado de novo, e não dado como garantido.

O que verificar antes do próximo aval a um projeto de IA

A instrução prática aqui é simples e imediata. Antes de assinar um contrato com um fornecedor de base de dados vetorial, e antes de destacar um engenheiro para construir um pipeline de sincronização da DynamoDB para uma base de dados vetorial, alguém deveria verificar se a própria DynamoDB já consegue fazer o trabalho sozinha.

Isto importa sobretudo para planos que já estavam escritos. Qualquer plano de projeto de IA redigido nos últimos dois anos que inclua uma linha para 'acrescentar uma base de dados vetorial separada' foi escrito sob pressupostos que a AWS acabou de mudar para quem usa DynamoDB. Reabrir esse plano custa uma tarde; não o reabrir custa um contrato com um fornecedor e um pipeline de manutenção que talvez não fosse necessário.

A própria verificação é restrita: os dados primários da aplicação já vivem na DynamoDB, e a escala e a latência exigidas cabem dentro do que a AWS publicou? Se as duas respostas forem sim, a base de dados vetorial separada passa a ser opcional em vez de pressuposta.

Onde uma base de dados vetorial separada ainda faz sentido

Nada disto significa que toda a base de dados vetorial dedicada deva ser retirada. Equipas que operam a escala extrema, ou em vários fornecedores de nuvem em simultâneo, podem continuar a ter razões que nada têm a ver com a nova capacidade da DynamoDB.

Arquiteturas já construídas e estáveis à volta da Pinecone, da Weaviate ou da Milvus também não precisam de mudar por causa de um único anúncio. Uma migração tem o seu próprio custo, e um sistema que funciona e cumpre os seus requisitos não merece automaticamente ser mexido.

A posição honesta é que isto é uma nova verificação, não uma obrigação. Algumas equipas vão fazer a verificação e manter a sua base de dados vetorial separada porque têm uma razão genuína para isso. O erro não está em verificar, mas em não verificar de todo e ficar-se pela velha suposição por hábito.

O que observar a seguir

A consequência mais imediata para as equipas de proteção de dados na UE e no Reino Unido é de conformidade: qualquer equipa que mude a sua pesquisa vetorial para a DynamoDB retira um segundo subcontratante e um segundo acordo de tratamento de dados da sua revisão de fornecedores, porque os dados dos utilizadores deixam de ter de passar por um fornecedor de base de dados vetorial separado.

Vale a pena observar como reagem os fornecedores dedicados de bases de dados vetoriais. Uma capacidade como esta, lançada pelo fornecedor que já detém uma grande parte dos dados subjacentes, é o tipo de movimento que costuma obrigar os concorrentes a diferenciarem-se com clareza ou a competir com mais força no preço.

Também vale a pena observar se outros grandes fornecedores de bases de dados na nuvem incorporam uma capacidade vetorial semelhante nas suas próprias bases de dados primárias nos próximos meses. Se o movimento da AWS for replicado noutros locais, o pressuposto de que as funcionalidades de IA exigem uma base de dados separada tornar-se-á ultrapassado muito para além da DynamoDB.

Leia a seguir: A carteira era 1,5 mil milhões. A obrigação também.  |  O lucro da escassez saiu como recompra