JOURN3Y LogoJOURN3Y
Data Foundations
September 21, 2026

Snowflake, BigQuery, Databricks: What Agents Need From a Data Platform

Back to Blog

If you are choosing a data platform, there is no shortage of comparisons. Almost all of them are written for a data engineering audience: performance benchmarks, pricing models, ecosystem maturity.

Those matter. But if part of the reason you are choosing is that you intend to put AI agents on top, the criteria shift, and the usual comparisons barely touch them.

What changes when agents are the consumer

A dashboard asks the same handful of questions on a schedule. An analyst asks varied questions but understands the model and knows which tables to trust.

An agent is neither. It asks unpredictable questions, at any hour, on behalf of someone who cannot check the SQL. That combination puts weight on four things.

1. Whether permissions live in the platform

This is the one that decides whether you can deploy at all.

If access control lives in the BI tool rather than the platform, then anything querying the warehouse directly bypasses it. An agent asking on behalf of a person needs the platform itself to know what that person may see — row-level and column-level, enforced at query time.

Snowflake, BigQuery and Databricks can all do this. The question is whether your implementation does, or whether governance was left to the dashboard layer because that was where the users were. In our experience this is the single most common gap, and it is an implementation choice rather than a product limitation.

2. Whether the semantic layer is real

An agent translating a question into a query needs to know what your business means by its own words. If "active customer" exists only in the head of an analyst, the agent will infer something plausible and be wrong in a way nobody notices for a month.

What matters is whether there is one definition, expressed somewhere the query layer can see, rather than which vendor's semantic tooling is more elegant. A modest, agreed set of definitions beats a sophisticated layer nobody populated.

3. Whether queries are cheap enough to be asked freely

Conversational analytics only works if people explore. Exploration means the follow-up question, and the one after that, most of which lead nowhere.

On a consumption model, a team that explores freely can generate a bill that prompts someone to restrict access — at which point you have reintroduced the queue you were trying to remove. Result caching, materialised aggregates and sensible warehouse sizing matter for a reason that is behavioural rather than technical: they decide whether people feel free to ask.

4. Whether it can be reached at all

Obvious, and routinely underestimated. Whatever sits on top has to have a connector, and that connector has to handle your authentication rather than a shared service account — otherwise every question is asked as the same user and the permissions work above is undone.

So which one

The honest answer is that for this purpose the differences between the major platforms matter far less than the state of your implementation.

Snowflake tends to arrive with governance features already switched on, which makes the permissions conversation shorter. BigQuery is usually already there if the organisation runs on Google, and being already there is worth a great deal. Databricks earns its place where the same platform carries data science and engineering work, so the AI layer sits alongside rather than downstream.

Any of them supports what an agent needs. We have built on all of them, and the platform has never been the reason a project struggled.

The uncomfortable conclusion

If you are choosing a platform partly to enable AI, the choice is less consequential than it feels. What decides the outcome is whether permissions are enforced where queries execute, whether your terms have agreed meanings, and whether people can afford to be curious.

Those are all implementation and governance questions. They follow you to whichever platform you pick.

Tags:
#Snowflake#BigQuery#Databricks#DataFoundations#DataPlatform