For an AI agent that must query live data across cloud and on-premises systems, Denodo’s example fits that topology: it federates Amazon Aurora, Amazon Redshift, and on-premises PostgreSQL at query time. AtScale’s example fits a different setup, where analytical data is consolidated in one warehouse and queries run there. AWS published the two tutorials on October 20, 2026; both connect an AgentCore-hosted Strands agent to a semantic layer through the Model Context Protocol (MCP).
A semantic layer gives an agent a governed model of business data, including definitions, relationships, and access rules. The choice between these examples turns on where the data lives and whether the workload needs to combine sources during a query.
Where each query runs
AWS’s Denodo tutorial describes Virtual DataPort planning queries across Aurora, Redshift, and on-premises PostgreSQL, then combining results from those sources. The example uses six base views, a derived customer-level view, and a separate reusable metric view. It does not require an ETL-built table that first combines the sources.
In AWS’s AtScale tutorial, the analytical Customer 360 data sits in Amazon Redshift Serverless, and each dimensional query resolves in one warehouse engine. The example replicates operational data from Aurora upstream into the analytical setup. That places the work of keeping the warehouse copy current before the agent’s query, rather than asking each query to federate those systems.
| Dimension | Denodo example | AtScale example | Practical implication |
| Data path | Federates Amazon Aurora, Amazon Redshift, and on-premises PostgreSQL at query time through Virtual DataPort. | Resolves each query in one warehouse engine; the example uses Amazon Redshift Serverless and describes upstream replication from Aurora. | Map the query to your current data layout: live joins across distributed sources match the Denodo pattern, while a consolidated warehouse and replication path match the AtScale example. |
| Semantic model | Base views, a derived customer view, and a reusable metric view; queries use VQL. | YAML-based Semantic Modeling Language (SML) objects include datasets, dimensions, facts, measures, calculations, perspectives, and row security; the model is versioned in Git. | The examples organize business definitions differently, so model structure and change practices are part of the architecture choice. |
| Agent connection | A Denodo MCP Server connects the agent to Virtual DataPort; AgentCore Gateway and Identity pass user identity through an On-Behalf-Of token exchange. | An AtScale MCP server connects the agent to the model; AgentCore Gateway and Identity manage the connection credential, and AtScale resolves the caller’s role. | Both use MCP, but their identity paths differ. Check which path matches how your application supplies user identity and roles. |
| Governance example | A Global Security Policy masks tagged ssn and card_num fields for marketing_user; the hr_user example sees them unmasked. | Role-based access control, row security, and perspectives govern the model; the marketing_user perspective omits the example’s ssn and card_num fields. | The examples show different treatments of sensitive fields: masking values in one and excluding fields from a perspective in the other. |
| Example deployment and protocols | The tutorial describes managed Denodo Agora or self-managed Denodo on Amazon EC2 or Amazon EKS. It lists JDBC, ODBC, ADBC, GraphQL, OData, and MCP. | The reference deployment is self-managed AtScale on Amazon EKS using its Helm chart and K8S Blueprints. The tutorial lists SQL, XMLA, and MCP. | Compare the deployment approach and interfaces with the systems your team operates and needs to connect. |
How the models define business data
Denodo’s example builds its model from source mappings, then adds a customer-level view and a separate view for reusable metrics. Queries use Denodo’s Virtual Query Language (VQL). That arrangement keeps source representations and shared business measures as distinct objects in the demonstrated model.
AtScale’s example represents the model in YAML through SML. Its objects cover datasets, dimensions and hierarchies, facts, measures, calculations, perspectives, and row-security rules, with model changes versioned in Git. Both tutorials place business definitions in the semantic layer, rather than relying on the agent prompt alone to define joins and measures.
What the access and audit examples show
The Denodo walkthrough applies a Global Security Policy to mask tagged sensitive columns for the example marketing role; its HR role sees those fields unmasked. The AtScale walkthrough combines role-based access, row security, and perspectives. Its marketing perspective leaves the example’s sensitive fields out of the model view.
The audit details highlighted in the tutorials differ. AtScale’s illustrative audit record includes the dimensional SQL generated for the model and the SQL translated for Amazon Redshift, along with identity, applied policies, aggregate use, and returned-row count. Denodo’s described audit trail records the VQL request, mapped role, federated query plan, and policy outcomes. These details let teams see what each tutorial’s example captures along the path from an agent request to data access.
Which pattern fits your data layout?
Choose the Denodo pattern as the closer match when an agent’s answer depends on joining data that remains distributed across cloud databases and an on-premises system at query time. Choose the AtScale pattern as the closer match when analytical data already resides in one warehouse and the organization can maintain an upstream replication path for operational data. Those are architecture-based choices drawn from the two examples, not a ranking of general product performance.
