The Data Warehouse Is Becoming an Operator

For most of its history, the data warehouse has waited.

A company sends product events, orders, support tickets, campaign results, financial records, and operational logs into one place. Analysts clean the data. Someone builds a dashboard. A manager eventually asks a question. The warehouse answers.

The sequence is human first, database second.

AI changes the sequence because it can remain connected to the warehouse between questions. It can inspect new evidence, run SQL, search documents, compare the result with a policy, write a finding into a table, invoke an approved tool, and return later to check whether the situation improved.

Snowflake now exposes several ways to build this relationship. The SQL API lets software execute queries and most data-definition and data-manipulation statements. Cortex Agents can combine structured analysis, document search, code execution, and custom tools inside Snowflake's governed environment. Snowflake's managed MCP server can expose SQL execution, Cortex Analyst, Cortex Search, Cortex Agents, stored procedures, and other tools to compatible AI clients.

The interesting development is not that an AI can write a query.

It is that the warehouse can participate in a continuing loop.

Use case 1: decide what is actually worth fixing

A product team usually has more possible improvements than it can implement.

Analytics show hundreds of abandoned steps. Support contains thousands of complaints. Performance tools report dozens of slow pages. Accessibility scans produce long lists of failures. Sales teams hear recurring objections. Developers know about fragile parts of the system. Designers have research notes that have never been connected to the quantitative data.

Each source is useful, but each source tells a different story.

A product analytics dashboard can identify where users leave. It cannot necessarily explain why they leave. A support ticket can explain one person's frustration, but it cannot show how common the problem is. A release log can show when the interface changed, but not whether the change caused a commercial effect.

An AI operator connected to the warehouse can triangulate these signals.

Imagine that mobile onboarding completion falls from 63 percent to 44 percent. The agent compares the decline across device types and acquisition channels. It searches support conversations from the same period and finds that customers repeatedly ask why a particular permission is required. It then checks the release history and discovers that a redesign moved the explanation below the permission request three days before completion began falling.

The useful output is not another chart.

It is a bounded conclusion:

The problem is probably not the permission itself. The explanation arrives too late. Move the reason above the request, then compare completion and support volume for seven days.

The system can record the finding, attach the supporting evidence, create the measurement window, and return after the next release. A person still decides whether to make the product change. The warehouse makes it harder for the recommendation to disappear after the meeting.

This is a specific use case for Snowflake because the platform can hold structured events, searchable text, release metadata, and the resulting audit history under one permission model. The same pattern could run elsewhere, but Snowflake's value appears when the evidence is already fragmented across departments and the answer needs to be shared, governed, and revisited.

Use case 2: find the customer who is about to leave

Churn models are not new. Companies have long scored accounts by declining activity, failed payments, contract dates, support volume, or product adoption.

The agentic version is more useful because it can reconstruct the situation around the score.

Suppose a business customer has reduced weekly usage by 38 percent. A conventional system adds the account to a risk dashboard. An AI operator can examine which features stopped being used, identify the first week of decline, compare the timing with support conversations, inspect unresolved incidents, and determine whether a billing or permission change affected the account.

It could produce a rescue brief for the account owner:

• usage declined after three team members lost access
• the administrator opened two support tickets about role configuration
• the tickets were closed technically, but the affected users never returned
• renewal is in 24 days
• restoring the original roles and offering a short training session is more relevant than sending a generic discount

The agent should not automatically contact the customer. That would confuse analysis with authority.

It can prepare the message, identify the evidence, propose the action, and wait for the account owner to approve or rewrite it. After the intervention, it can check whether the users returned and whether the account renewed.

The loop matters more than the prediction.

A churn score says who might leave. An operator keeps track of what the company tried and whether the intervention worked. Over time, the warehouse becomes a memory of effective responses rather than only a collection of risk labels.

Use case 3: locate where the business is quietly losing money

Many operational problems do not look dramatic enough to trigger an incident.

A marketplace may still be growing while one category becomes unprofitable. A delivery company may complete more orders while refunds rise faster than revenue. A subscription product may acquire more users while a promotional rule accidentally gives expensive discounts to customers who would have paid full price.

These problems often exist between dashboards. Finance sees margin. Operations sees fulfilment. Product sees conversion. Support sees complaints. Nobody sees the entire mechanism.

An AI operator could watch for combinations rather than isolated thresholds.

Consider an online retailer. Gross revenue looks healthy, but contribution margin falls in one region. The agent traces the change to a particular group of bulky products. Those products received a new promotion, which increased orders. The shipping estimator still uses an older packaging rule, so the actual delivery cost is much higher than the checkout estimate. Customers are also returning the products more often because the promotional page creates a misleading expectation about size.

The result is not simply "shipping costs increased."

It is a causal chain:

A promotion increased demand for products whose packaging data is outdated. The inaccurate shipping estimate and elevated return rate make the campaign unprofitable in this region.

The agent can prepare three actions: pause the campaign for the affected products, request a packaging-data correction, and create a monitor that compares estimated shipping with actual shipping after the correction.

Again, the valuable part is not automatic execution. It is compressing the distance between detection, explanation, action, and verification.

Use case 4: install expertise inside the client's data boundary

A consultancy or software company often wants to analyse customer data without asking the customer to export sensitive information into another vendor's database.

Snowflake Native Apps create a different distribution model. A provider can package application logic, stored procedures, functions, and a Streamlit interface. The customer installs the app in its own Snowflake environment and grants it access to selected objects. The analysis runs close to the customer's governed data rather than requiring a duplicate external data estate.

This could support a product-assurance application that reads approved product events, support themes, performance results, and release history. The app could display current risks, evidence, recommended interventions, and before-and-after outcomes. The customer controls which views are available. The provider distributes the evaluation logic and interface.

The commercial product is therefore not "give us your data."

It is:

Install our method where your data already lives.

This is one of Snowflake's more distinctive use cases. BigQuery, Databricks, and Redshift can all support applications and governed analysis, but Snowflake has made provider-to-consumer data products, secure sharing, listings, and Native Apps a central part of the platform's design.

A specialist company could begin with a service, observe recurring analysis patterns, encode them into tables and procedures, add an AI operator, and eventually distribute the system as a customer-installed application.

The service becomes software without requiring the customer to surrender control of the underlying evidence.

Use case 5: let AI maintain the analytical system itself

The warehouse also has its own operational problems.

Tables stop updating. An API changes a field name. A transformation begins duplicating rows. A new dashboard runs an expensive query every few minutes. A team creates five slightly different definitions of active customer. A source system adds a column that nobody documents. A scheduled pipeline succeeds technically but delivers yesterday's data.

Data teams spend a surprising amount of time discovering and repairing these failures.

An AI data steward could watch freshness, schema changes, row counts, query history, warehouse consumption, lineage, and test results. When something changes, it could investigate before alerting a person.

Instead of reporting "table failed freshness check," it could explain:

The orders table is current, but the customer-status transformation stopped at 02:14 because the source changed plan_type from text to a nested object. Three dashboards now contain stale customer segments. Here is the proposed transformation update and the affected downstream assets.

The agent can create a branch or draft change, run tests against a development schema, and prepare a review. A data engineer approves the migration. The agent then watches the next production run and closes the incident only when the downstream tables become current.

This is where an AI-controlled warehouse becomes closest to an operator in the traditional sense. It is not only analysing the business. It is maintaining the system that produces the analysis.

Control does not mean giving the AI the whole account

The screenshot that begins many Snowflake trials shows the ACCOUNTADMIN role. That is a sensible role for initial account setup and a terrible role for an autonomous agent.

A useful operator should have a narrow role designed around a job.

It might be allowed to read secure views containing product events and support data, execute queries on an isolated small warehouse, write findings into one audit schema, call a specific stored procedure, and update the status of its own recommendations.

It should require approval before changing schemas, contacting customers, moving money, modifying permissions, deleting objects, or writing into production systems.

This separation is not an inconvenience added after the AI becomes capable. It is the design of the product.

The important questions are:

• Which objects can the agent see?
• Which queries can it run?
• Where can it write?
• Which external tools can it invoke?
• Which actions are reversible?
• Which actions require a visible human decision?
• How is every action logged and reviewed?

The agent should be able to do enough work to reduce friction, but not enough to make institutional responsibility disappear.

Snowflake is not the only answer

The phrase "Snowflake alternative" makes several different products sound interchangeable. They overlap, but they begin from different centres of gravity.

| Platform | Centre of gravity | A natural fit when... | Less natural when... | |---|---|---|---| | Snowflake | Governed analytical data, independent compute, sharing, data applications, and agent access | Business data spans teams, customers need governed access, or an application should run near customer data | The entire problem is one small operational database or a local file analysis | | Databricks | Lakehouse engineering, large-scale processing, streaming, machine learning, and AI development | Data engineering, model development, notebooks, open table formats, and ML operations are central | The team mainly wants a straightforward SQL warehouse and business-facing data application | | BigQuery | Serverless analytics inside Google Cloud | The organization already uses Google Cloud and wants minimal infrastructure management with SQL, Python, and Gemini-assisted analysis | The product requires Snowflake-style provider and consumer distribution as its main architecture | | Amazon Redshift | AWS-native analytical warehousing | Operational systems already live in AWS and zero-ETL integrations, S3, IAM, and AWS administration matter most | The company needs a cloud-neutral data-product ecosystem | | PostgreSQL or Supabase | Transactional application state | One product needs users, permissions, forms, payments, and low-latency reads and writes | Many departments need independent analytical compute over large historical datasets | | DuckDB | Embedded and local analytical SQL | One person or application needs to analyse files quickly without operating a server | Many teams need shared governance, workload isolation, continuous ingestion, and customer distribution |

Databricks becomes especially compelling when the warehouse is only one part of a broader engineering and AI platform. Its lakehouse architecture, Unity Catalog, model lifecycle, streaming, and agent framework place more emphasis on the path from raw data to production intelligence. Its Genie products also provide natural-language access to governed organizational data.

BigQuery removes much of the warehouse-management surface. Its serverless architecture is attractive when the team wants to submit analytical work without deciding which warehouse should be running. Gemini in BigQuery can assist with SQL, data preparation, insights, and visual analysis. Data canvas turns an investigation into a graphical workflow, although Google explicitly positions it for data professionals rather than direct business-user consumption.

Redshift is a strong extension of an AWS organization. Serverless removes the need to operate a permanent cluster, while zero-ETL integrations can replicate data from AWS databases, DynamoDB, and supported applications into Redshift. Its advantage is often proximity to the systems, identities, billing, and operational conventions the company already uses.

PostgreSQL and DuckDB are reminders that not every company needs a data cloud. A small product can often answer its important questions with Postgres views, a scheduled job, and a lightweight dashboard. An individual analyst can do serious local work with DuckDB. Adding Snowflake before the organization has a real multi-source, multi-team, governance, or scale problem can turn architecture into theatre.

The correct question is not "Which platform has AI?"

They all increasingly do.

The question is which kind of work needs to become continuous.

The chatbot is the least interesting interface

The first AI layer added to a data platform is usually a chat box.

Ask a question. Receive a chart. Request a different grouping. Generate a summary.

This is useful, but it preserves the old model of the warehouse. The system still waits for a human to remember that a question needs to be asked.

The more consequential interface may be an inbox of prepared decisions:

• onboarding completion declined after a release
• one customer needs a specific rescue action before renewal
• a campaign is profitable in total but losing money in one region
• three dashboards are stale because a source schema changed
• last week's intervention improved conversion but increased support volume

Each item would include the evidence, the confidence, the proposed action, the permissions required, and the measurement that will determine whether the action worked.

The human does not need to begin with a blank prompt.

The system brings forward situations that have crossed a meaningful threshold.

This is the difference between conversational analytics and supervised operations.

Conversational analytics makes the warehouse easier to question.

Supervised operations makes it harder for important evidence to be ignored.

The warehouse becomes valuable when it remembers the outcome

An AI agent can easily create activity. It can run hundreds of queries, generate dozens of findings, and fill a dashboard with urgent-looking recommendations.

That is not automatically intelligence.

A useful system needs to remember what the organization decided, what action was taken, what result followed, and whether the original explanation was correct. Without this memory, the agent repeatedly rediscovers the same problem and produces the same advice.

The durable data model may be surprisingly simple:

Signal → finding → evidence → decision → intervention → outcome

This structure turns analysis into organizational learning.

The product team can see which recommendations were accepted. The data team can see which signals produced false alarms. The business can compare different interventions. The agent can become more conservative when similar recommendations have repeatedly failed.

The data warehouse was originally designed to preserve a historical record of the business.

The next step is to preserve a historical record of the business learning from itself.

That is the use case.

Not an AI that owns the company.

An evidence system that notices, prepares, waits, and checks.

The data warehouse is becoming an operator.

The human still decides what it is allowed to operate.

Connected reading

• The Product Needs a Harness
• The Coding Assistant Is Becoming the Development System
• The Browser Is Becoming the Agent's Body
• Every Website Has an Algorithm

AI authorship note

This essay grew from Kris Haamer asking how Snowflake could be controlled by AI, then pushing the explanation away from a generic company pitch and toward specific operational use cases. AI supported current platform research, comparison, drafting, editing, SVG illustration design, and implementation. Kris chose the product-triage direction, requested the comparison with adjacent tools, and made the decision to publish the article on Raw Drafts.