Nos exemplos publicados pela AWS em 20 de outubro de 2026, o Denodo consulta fontes distribuídas durante a execução da consulta; o AtScale resolve cada consulta em um único mecanismo de data warehouse. Para escolher entre os padrões, o ponto de partida é a topologia que sua equipe já tem: fontes que precisam ser cruzadas em tempo real ou dados analíticos consolidados com replicação prévia.
Os dois tutoriais conectam um agente Strands hospedado no Amazon Bedrock AgentCore a uma camada semântica por meio do Model Context Protocol (MCP). A partir desse caminho comum, as arquiteturas seguem direções diferentes.
| Dimensão | Exemplo com Denodo | Exemplo com AtScale |
| Onde os dados são consultados | O Virtual DataPort federa Amazon Aurora, Amazon Redshift e PostgreSQL local e combina os resultados. | As consultas analíticas são resolvidas em um único mecanismo; o exemplo usa Amazon Redshift Serverless. |
| Preparação dos dados | As fontes permanecem distribuídas; o exemplo não depende de uma tabela combinada criada por ETL. | Os dados operacionais do Aurora são replicados previamente para compor o ambiente analítico. |
| Modelo semântico | Views base, views derivadas e uma view de métricas reutilizável, consultadas com VQL. | Objetos YAML da Semantic Modeling Language (SML), versionados no Git. |
| Exemplo de controle de acesso | Uma política mascara campos marcados como sensíveis para marketing_user; hr_user vê esses campos sem máscara. | Controle de acesso baseado em função, segurança por linha e uma perspectiva de marketing que omite campos sensíveis do modelo. |
| Caminho do agente | O servidor MCP do Denodo conecta o agente ao Virtual DataPort; o exemplo usa troca de token On-Behalf-Of para propagar a identidade. | O servidor MCP da AtScale conecta o agente ao modelo; o AgentCore Gateway e o Identity gerenciam a credencial, e o mecanismo AtScale resolve a função de quem chamou. |
Consultas em fontes distribuídas ou em um único warehouse
No tutorial do Denodo, o Virtual DataPort planeja consultas federadas entre Amazon Aurora, Amazon Redshift e uma instância local de PostgreSQL, envia operações às fontes e combina os resultados intermediários. A modelagem apresentada inclui seis views base, uma view derivada no nível do cliente e outra, separada, para métricas reutilizáveis.
Esse arranjo se encaixa no padrão ilustrado quando uma resposta precisa cruzar fontes que continuam em ambientes diferentes, inclusive dados locais e na nuvem. A arquitetura não exige que o exemplo reúna tudo primeiro em uma tabela analítica única.
O tutorial do AtScale parte de outra organização: os dados analíticos Customer 360 ficam no Amazon Redshift Serverless, e cada consulta dimensional é resolvida em um mecanismo de warehouse. Os dados operacionais do Aurora são replicados para esse ambiente antes de serem consultados. Assim, o padrão depende de uma cópia analítica alimentada a montante, em vez de federar fontes distintas durante cada consulta.
Se a consulta precisa combinar dados distribuídos no momento em que o agente pergunta, o caminho mostrado pelo Denodo corresponde melhor a essa topologia. Se a equipe já concentra os dados analíticos em um warehouse e mantém a replicação necessária, o exemplo da AtScale se aproxima mais do cenário. Essa é uma escolha baseada nos limites de execução descritos nos tutoriais, não uma conclusão sobre velocidade ou desempenho relativo.
Como cada camada representa as regras de negócio
O exemplo do Denodo organiza a semântica em views base, que mapeiam as fontes, views derivadas e uma view própria para métricas. As consultas usam VQL. Essa estrutura separa os dados de origem das definições reutilizáveis que o agente pode consultar.
A AtScale usa objetos YAML da SML para descrever conjuntos de dados, dimensões, hierarquias, fatos, medidas, cálculos, perspectivas e segurança por linha. O tutorial versiona esses objetos no Git. Em ambos os casos, definições de negócio e controles ficam na camada semântica, em vez de dependerem apenas das instruções enviadas ao modelo de linguagem.
Identidade, governança e auditoria
Os tutoriais mostram controles diferentes. No exemplo do Denodo, uma Global Security Policy mascara os campos marcados ssn e card_num para marketing_user; a função hr_user vê esses campos sem máscara. O exemplo da AtScale combina controle de acesso baseado em função, segurança por linha e perspectivas: a perspectiva de marketing deixa de expor os campos de SSN e cartão no modelo de exemplo.
A trilha de auditoria também aparece de formas distintas. O registro ilustrativo da AtScale inclui o SQL dimensional gerado pelo modelo de linguagem e o SQL convertido para execução no Redshift. O tutorial do Denodo destaca a solicitação em VQL, a função mapeada, o plano federado e os resultados das políticas de acesso. Esses exemplos mostram quais informações as respectivas demonstrações registram; não constituem uma comparação completa de auditoria nem determinam se os controles atendem às obrigações de uma organização.
As duas implementações também usam o AgentCore para conectar o agente ao endpoint MCP, mas o tratamento de identidade não é idêntico. O Denodo descreve a propagação da identidade por uma troca de token On-Behalf-Of. No exemplo AtScale, o AgentCore Gateway e o Identity gerenciam a credencial da conexão, enquanto o mecanismo AtScale identifica a função de quem fez a chamada.
Opções de implantação e alcance dos exemplos
O tutorial do Denodo descreve o Denodo Agora como opção gerenciada e também cita implantações autogerenciadas em Amazon EC2 ou Amazon EKS. A referência da AtScale usa uma implantação autogerenciada no Amazon EKS, com o gráfico Helm e os K8S Blueprints da empresa.
A AWS relata três categorias de consulta e uma nova execução com controles de governança em cada tutorial. São demonstrações dos padrões apresentados, não uma comparação controlada de latência, custo, escala ou eficácia de segurança entre os produtos. Para a decisão arquitetural, portanto, a localização dos dados e a necessidade de cruzá-los durante a consulta são critérios mais úteis do que presumir um vencedor geral.
