AI Agent Data Access Patterns Across Snowflake, BigQuery, and Redshift

Customer data used to sit downstream of the CRM, waiting to be queried by whoever ran the periodic dashboard review. That's no longer how the data actually moves. CRM records now flow into Snowflake, BigQuery, or Redshift on hourly or faster cadences at most mid-market and enterprise accounts, and the warehouse has quietly become the place where the real answer lives, while the CRM record is only where the chain started. An AI agent that only reads the CRM will tell a rep that Acme Corp is a 500-person SaaS company. An agent that reads the warehouse will tell the rep that Acme is inside its renewal window, engagement has been sliding for three weeks, and there's an open expansion conversation sitting in the pipeline. Those are different products, and the difference comes entirely from where the agent is allowed to look.

Why each platform's architecture produces fundamentally different access primitives

Snowflake, BigQuery, and Redshift all sit on the same basic foundation: columnar storage, massively parallel execution, cloud-native deployment, and full SQL support. None of that is where they diverge. The differences that actually matter for an AI agent appear in how compute is scaled, how tightly compute is bound to storage, and what happens to a query when nobody's watching the clock.

Snowflake split storage from compute at the outset. Independent virtual warehouses, sized from XS up through 6XL, all read from the same shared object storage layer, and several of them can hit that same data at the same time without stepping on each other. Each warehouse suspends itself when idle. That architecture, built in from day one rather than retrofitted, is what makes clean workload isolation possible for an agent sharing infrastructure with human analysts.

BigQuery goes further toward abstraction than either of the other two. In the on-demand model there's no cluster to size at all: a SQL statement goes in, and Google's Dremel engine hands out compute slots dynamically behind the scenes, with storage billed on its own separate meter. For an agent, that means idle cost approaches zero, but the pricing runs on bytes scanned, and a wide table hit by a high-frequency agent loop turns into a real cost line fast.

Redshift started life the old way: nodes with storage physically attached to them. The RA3 node types broke that coupling, moving data into S3-backed managed storage while the nodes handle compute and local caching, and Redshift Serverless removes cluster management as a task for the user. Even so, an agent talking to Redshift still inherits a cluster-shaped mental model, serverless or not. That legacy shapes how workload contention gets handled once agent traffic joins the queue.

Snowflake's access model for AI agents: Cortex, semantic layers, and workload isolation

Cortex Agents is Snowflake's fully managed answer to agentic orchestration, and it sits entirely inside Snowflake's own governed environment. An agent takes a request, plans out the steps, calls whatever tools it needs, runs the code, and returns an answer, all without an operator standing up a separate orchestration loop or hosting a runtime somewhere else.

What the agent can actually see is governed by ordinary Snowflake privileges plus the execution context attached to each tool it's configured with. Structured data comes through Cortex Analyst semantic views. Unstructured sources come through Cortex Search and embeddings. Anything custom runs through stored procedures or integrations built for the purpose. It's the same permission model that's governed human users on Snowflake for years, just extended to a new kind of caller.

Snowflake Intelligence wraps this into something closer to an enterprise assistant: natural-language questions over both structured and unstructured organizational data, agentic reasoning with governance and security built in, and support for MCP. Underneath, it's spinning up Cortex Agents to do the actual work.

Where inference happens is the detail that matters. Snowflake Cortex runs LLM inference, including Mistral 7B, Llama 3, and Snowflake's own Arctic model, directly against warehouse data with no external API call in the loop. Data doesn't leave the governed environment to get an answer. For any enterprise data team worried about where customer records travel once an AI product touches them, that's not a minor implementation detail. It's the whole argument.

BigQuery's access model for AI agents: serverless queries, MCP, and the bytes-scanned trap

Google put a Remote BigQuery MCP Server into preview in January 2026. It runs on Google's own infrastructure and exposes an HTTP endpoint that AI applications can talk to, using the MCP standard to let a client and server communicate cleanly. In practice, it hands LLM-powered applications direct access to analytics data through a defined set of tools, rather than making every integration team write its own connector from scratch.

BigQuery's tie-in with Vertex AI is arguably the most mature model-training path of the three platforms. AutoML, custom training containers built on TensorFlow or PyTorch, and a full model registry are all reachable from the BigQuery interface itself, which matters for teams that want to train and serve models directly on warehouse data rather than exporting it somewhere else first.

BigQuery also has a real edge with semi-structured data. Nested JSON, arrays, and other non-flat formats run through BigQuery without a lot of manual schema wrangling beforehand, which counts for a lot when an agent is reasoning over event streams or document-style records rather than clean rectangular tables.

None of that erases the pricing risk, though. On-demand pricing is $6.25, with no confirmed 25% cut as of March 1, 2026, and the model bills by bytes scanned. That's a fine deal for workloads that fire occasionally and unpredictably. It's a bad deal for an agent hitting a wide, poorly partitioned table once a minute, the same way a dashboard that refreshes too often on unpartitioned data has surprised more than one finance team with the bill.

Redshift's access model for AI agents: Lake Formation governance, AWS-native data paths, and the AI capability gap

Redshift's defining trait is how deep it sits inside the AWS ecosystem. IAM, Glue Catalog, S3, and Kinesis are all native, not bolted on, and Redshift Spectrum can query S3 directly, letting one SQL statement join a warehouse table against a data-lake table without any intermediate step. For an agent that needs to cross the line between warehouse and lake in a single query, that's a real capability, not a convenience feature.

Zero-ETL integrations are where Redshift has been putting its recent effort, pulling streaming operational data into the warehouse with a lot less pipeline overhead. That directly attacks staleness, which is the thing most likely to undermine an agent's grounding: an answer built on data from six hours ago offers little advantage over an answer built on no data.

Governance is the strongest argument for Redshift in this context, and it's a structural one rather than a marketing one. SQL running through Amazon Athena or Redshift Spectrum inherits whatever Lake Formation permissions already govern that data, and agent queries routed through those same paths benefit from the same controls. An agent can't see more than the human user it's acting for could see, and the broader AWS governance tooling provides auditability hooks for those queries. According to an analysis, three AWS-bound pilots that moved from a broad analyst group to a view-scoped AI role saw "unexpected PII column" review flags drop to zero within the first month, with no change made to the loader itself. That's governance doing real work, not governance as a compliance slide.

Access patterns that work across all three platforms and the anti-patterns that fail in enterprise contexts

Across Snowflake, BigQuery, and Redshift, the pattern that actually holds up in production is the same: federated reads run against the customer's own warehouse, the data never leaves the customer's account, and query results stream into the agent's reasoning layer, get used for that one answer, and are discarded. Nothing sits around waiting to be a liability later.

The anti-pattern is asking the customer to export the relevant tables on some schedule and hand them over. It fails on data residency. It fails on freshness, since a nightly export is stale the moment anything changes intraday. And it fails on governance, because now there's a second copy of the customer's data sitting somewhere new that their security team never signed off on. Any enterprise data engineering team running a modern cloud stack will flag this as backwards on sight, and they'd be right to.

Schema discovery has to be a built-in first step, not an afterthought. On first connection, the integration needs to enumerate the customer's actual databases, schemas, and tables, so that whoever is writing queries, a CS engineer or the customer's own data team, is working against the real schema rather than one assumed from a sales call six months earlier.

Workload isolation plays out differently depending on the platform. AI agents throw off bursty, exploratory SQL by nature, and on Redshift that traffic collides head-on with ETL and BI jobs if everything's stacked in one default queue. Snowflake's multi-warehouse model handles exactly this kind of contention cleanly. BigQuery's serverless model avoids fixed-queue contention by design, but the bytes-scanned cost exposure doesn't care whether the query came from a human or an agent, it bills the same either way.

Embedding Warehouse-Native Agent Access Without Building Connectivity Infrastructure

Every pattern described above, federated reads, schema discovery, workload isolation, comes with its own tangle of auth to manage: each platform with its own authentication model and quirks, none of them interchangeable. Building that correctly for one warehouse is a serious project on its own. Building it for three, with data residency guarantees and workload isolation holding up under real customer load, turns into an infrastructure commitment that starts competing directly with the product work that actually differentiates a company.

The more useful way to think about it: the connectivity layer that already serves human users reading dashboards doesn't need a separate build for AI agents. The agent is just a new consumer showing up on the same integration surface, reading the same warehouse through the same access controls.

That's the gap embedded connectivity platforms exist to close. Embeddable SDKs and APIs let a product team ship read access to Snowflake, BigQuery, and Redshift as a feature they turn on, rather than an infrastructure project they staff up for. Pricing that scales with destinations rather than data volume matters here too: a team shouldn't get penalized on their bill just because agent query volume climbed.

Multi-tenant isolation can't be treated as an afterthought. Every customer's agent has to reach its own warehouse through its own isolated credentials, and any mixing of credentials across tenants is a security failure, full stop. That has to be designed against from the start, not patched in once someone notices the risk.