I really wish they’d just throw the entire UI in the trash. Why am I forced to look at a "canvas" for the runtime? Can’t they make the parameters and configuration settings actually visible and accessible?

On top of that, I’m trying to create a Gen2 instance, but the runtime I’ve created doesn’t even show up. It’s just the worst.

They confirmed at Summit that they plan to overhaul this garbage UI, but looking at Snowflake’s recent updates—where they’re only focusing on minor bug fixes—it’s clear that this feature has essentially been abandoned.

It’s not like there’s even a wide variety of connectors, either... honestly, it’s just the worst.

It seems they’re enabling Gen2 to be handled via queries, which could be a potential advantage—but then again, not everyone wants to work with queries.

First and foremost, a fully realized UI is essential. Snowflake is in dire need of an overall UX designer; it’s honestly baffling how little attention they pay to UI/UX.

We need to get an account setup for our business. We are trying to go through the trial signup but get this every time. The account needs to be in aws on a specific region. Anyone have any way to expedite a solution from snowflake. Created a community account on their community support page but it appears that the community support page is just for people to report and complain about issues with no answers or resolution from snowflake.

Do I need to contact sales? It really bothers me when companies make it hard to take my money.

I'm slowly starting to build out the semantic layer now that my organization's end users have access to Claude and I have to get it talking to our data warehouse.

As I was finalizing a view, I was writing in the comment for it but realized I was describing a record in that view, and not fully describing the view. If there's a big difference for the semantic layer and Claude, should I be describing the object or a record in the object? I couldn't find any guidance on this online so any help/suggestion would be much appreciated

Hey guys,

I don't know about you, but I am not a big fan of documentation and I constantly find myself struggling to keep up with all the new Snowflake features, documentation, and updates.

There's just so much stuff coming out all the time, its awesome but also crazy to keep up with

So I figured I'd try something different.

I started a little YouTube channel called Snowflake Under the Hood, where I try to make super short digestible videos explaining small Snowflake hacks, features, and concepts.

Would genuinely love to hear what you guys think. Are they actually helpful? What would you improve (besides the cheesy storylines LOL)?

I really want to make this easy for people to understand and digest super fast.

And are there any Snowflake features you'd like to cover?

Don't hold back. (just don't be mean) 😅

https://www.youtube.com/@SnowflakeUndertheHood

I know the videos are still a bit kitschy and definitely need some work. this is a super new project 😂 but so far I'm having fun making them.

Hey,
We are about to go into a renewal of our Snowflake contract and I am wondering if some of you are able to share discounts you are receiving on your credits? Right now the offer I have received are not that relevant because they don't actually take our actual consumption into account, but use their own predictions (which of course is much higher than ours).

We estimate our consumption to around 120K USD in a year and can get 15% off on our credits now it seems, leaving us at one credit costing 3.32USD (list price is 3.9). If we commit to a higher consumption we might get a higher discount, but that doesn't seem to make any sense atm.

hey, does anyone have purchase the official practice test and then make the certification exam? are they similar? I'd like to read some experiences about that

Thank you!

We run a Cortex Agent in production through Snowflake CoWork (a text-to-SQL analytics agent on top of a semantic view). We noticed that a few users with long conversations drive a disproportionate share of our credit costs. We sent Snowflake a feature request about it, but I'd like to hear how others deal with this.

What we observed (SNOWFLAKE_INTELLIGENCE_USAGE_HISTORY)

User B makes only a fifth as many requests, but each one costs about 5x more, so total cost ends up about the same.

Root cause (TOKENS_GRANULAR)

On every turn, Snowflake Intelligence sends the full conversation history, including tool calls and results, back to the LLM as input. In our data, the cache_read_input tokens grow roughly linearly with each turn:

• Turn 1: ~30,000 tokens (system prompt + semantic view definition)
• Turn 5: ~1,300,000 tokens
• Turn 12: ~2,960,000 tokens

By turn 12, a single question costs about 2.16 credits.

Missing configuration

The agent specification currently offers:

• budget.tokens: limits output generation per turn, not history input
• budget.seconds: timeout

There is no way to control how much history gets sent on follow-up turns. Something like this would solve it mb:

conversation_memory:
  max_turns: 5            # only send the last N turns
  max_tokens: 500000      # cap history input
  strategy: sliding_window  # or: summarize

• Sliding window: keep only the last N turns
• Token limit: drop the oldest turns once history reaches X tokens
• Summarization: replace older turns with a summary

Our current workaround

We train end users to start a new conversation regularly. That works in theory, but it isn't a sustainable approach for a production deployment.

Questions to the community:

• Are you seeing the same token growth in long Snowflake Intelligence conversations?
• Can anyone confirm what actually drives the growth? Our guess is that the chat history alone doesn't add up to ~3M tokens by turn 12, so the tool results (generated SQL, query result sets, semantic view context) probably get re-sent on every turn. Has anyone broken this down in TOKENS_GRANULAR?
• How much does prompt caching actually help? Cache-read tokens are billed at a lower rate than fresh input, yet we still end up at ~2 credits per request. Are your effective costs per turn similar?
• Has anyone found a way to cap or trim history? For example, a custom frontend on the Agents REST API where you control which messages get sent?
• Any tricks for keeping tool outputs small, so each turn adds less to the history?
• Do you monitor or alert on per-conversation cost, and if so, how (queries on TOKENS_GRANULAR, budgets, resource monitors)?
• Has anyone heard whether Snowflake plans to add a memory or context setting to the agent spec?

Any experiences or workarounds are welcome. Thanks!

We're an EU-based company consolidating our AI workloads on Snowflake, and we recently sent a feature request to Snowflake. I'd like to hear how others are handling this.

Our situation

Claude models work fine for us in AWS EU through cross-region inference. Several model families can't be reached through AWS EU cross-region at all, though:

• OpenAI (gpt-5, gpt-5-mini, gpt-5-nano, gpt-5.1, gpt-5.2) only through AWS US or Azure US cross-region
• DeepSeek R1 only in AWS US
• Qwen (qwen3-32b, qwen3-next-80b-a3b) only in AWS US and Azure US
• The latest Claude Opus models (opus-5, opus-4-8, opus-4-7) are not in AWS EU cross-region either

The Cortex REST API has the same gaps: in the EU we only get llama3.1, mistral and Claude.

Because of GDPR data residency, sending data to US regions isn't an option for us.

Image generation: not there yet, but apparently on the way

Cortex can already read images (multimodal AI_COMPLETE, AI_PARSE_DOCUMENT), but generating images isn't generally available yet. I've heard that something is coming, though I haven't found any official details on timing, which models it will use, or which regions it will be available in. For us, that last point matters most: if it launches US-only like the OpenAI models, it won't help EU customers for a while.

Ideally it would be a SQL function (something like AI_GENERATE_IMAGE) plus a REST API endpoint, for marketing content, product visuals and report illustrations.

The bigger idea: a GenAI Hub inside Snowflake

With full model coverage and image generation, Snowflake would have everything needed for a governed, enterprise-grade alternative to ChatGPT, Claude or Gemini that runs inside your own security perimeter. Authentication, RBAC, audit logging and data governance are already built in. Even if Snowflake doesn't ship it as a product, customers could build it themselves with Streamlit in Snowflake or Snowflake Apps.

For now we still run separate external infrastructure for OpenAI, Claude (for design) or other model provider solutions, e.g. for image, text or other content generation. That adds complexity and splits our governance. Something I would like to centralize and there came the idea in to put such GenAI Hub on top of Snowflake.

My questions to the community:

Has anyone built something like this, a ChatGPT-style GenAI hub on top of Cortex, ideally in an account without region restrictions for compliance reasons (e.g., US-based, or with cross-region inference set to ANY_REGION)?

I'd especially like to know:

• What did you build it with (Streamlit in Snowflake, Snowflake Apps / SPCS, a custom frontend on the Cortex REST API)?
• How did you handle multi-model switching, chat history and file uploads?
• Did you add image generation somehow (an external API through an External Access Integration, a model you host yourself on SPCS)?
• Has anyone already seen or tested the upcoming image generation feature (e.g., in private preview)? Any word on EU availability?
• How has adoption been compared to giving people direct access to ChatGPT, Claude or Gemini?
• Have any EU folks found a workaround that compliance actually signed off on?

Any experiences, architecture sketches or lessons learned are welcome. Thanks!

Now that Postgres mirroring is GA, I spent some time in the docs figuring out what it actually bills for, because "no pipeline" sounded a bit too good.

Here's what I found:

• Each mirror gets its own serverless apply task (APPLY_MIRROR_<name>), which makes attribution easy in serverless_task_history.
• Ongoing apply does delete-then-append instead of MERGE, so insert-heavy tables are cheap to keep in sync.
• refresh_interval (30 seconds to 1 day, default 10 minutes) is basically the price dial. Every table also gets a $live view with about 30 second freshness no matter the interval, so I'd keep the interval long and point the people who need fresh data at $live. I couldn't find anything on what $live queries cost compared to the regular table, so I'd measure that before hooking up a busy dashboard.
• On the Postgres side, the walsender runs at elevated CPU priority by default, so a busy instance can slow down your app's writes.
• If the WAL backlog passes max_slot_wal_keep_size, the slot gets invalidated and every table re-snapshots. DESCRIBE_MIRROR shows push and apply lag, so it's worth alerting on.

Full write-up with the monitoring queries: medium.com/@yanivleven

Is anyone running this in production yet?

Iam testing snowflake table with ARRAY column. In Snowflake, the datatype is ARRAY but when I read the same table through Spark, it shows up as STRING

Is this expected behavior from the Snowflake Spark Connector, or could it be caused by the JDBC driver or schema inference?

If anyone has handled this, how do you preserve the array structure instead of treating it as a string?

Looking for feedback from people that have used both. My previous employer paid for dbt Cloud and it was a great tool that acted as our IDE, scheduler/orchestrator and provided other insights as well.
I posted about dbt Projects here a while back and they seemed to garner mixed feedback from this crowd.
Has anyone moved from dbt Cloud to dbt projects in Snowflake (or vice versa)? What are your thoughts?
Having never used dbt outside of my experience with dbt Cloud, I will say that one of the biggest advantages of Cloud was the ability for all developers to have their own schema to develop in (no object contention when developing on the same set of objects/in the same schema with other devs).
I don't know if I've seen any other tool/feature offer such an advantage.
Anyways, if you have experience with both please provide your thoughts!

Hi Snowflake Community on Reddit.

I created already some analytics agent. Pretty easy and well efficient.

One agent, one semantic view with well prepared entities and joins, some great instructions and limitations. Next to that verified queries. Absolutely awesome and not that much expensive, because the majority of request turn into sql query results and let the AI do the easy and shorter part.

But...

Last week I created a more complex agent. And the more complex things are the input data. I used unstructured data and extracted data per page into a content column, put a search service on top and it works in general. All in all there are 25k new rows with paginated data in one column.

Within my monitoring streamlit, obviously, I can see that the agent uses a lot more AI functions to find and extract the right information.

Currently, there is a small ETL python SP in SF behind, which extracts deltas or differences every sunday to stay up-to-date.

I thought if it would be an idea to extract the important data out of the content column per page into separated columns, to be more effective in finding the right results or filtering it. Do you have any experiences with that?

Or any other ideas to speed up finding results with paying less money for it? (AI activities on the agent)

It's not possible to fully go to structured data because these documents are created within the business area as a regular process.

Pretty much I have 0 idea where to start with this. Apparently the team who started the mass migration to snowflake got confirmation it was possible to use snowflake postgres and AWS lambda and gcp functions.

Coco doesn't give me anything useful and Claude. Wants to do massive networking changes to make it possibly work. I can barely find any documentation from snowflake.

So any tips or suggestions?

Hi everyone,

I have 4 yoe it's my first switch on snowflake dbt.

In interviews there was always a question which I am not able to give a solid answer. (I haven't worked on any AI implementations).

What snowflake AI features you have implemented in your project??

I know we use coco, semantic views we haven't implemented in our project no hands on. (Please add some more If you worked on).

Please help me with AI implementations in Snowflake.

Any courses to go through?? How to improve my knowledge in AI and give a proper answer in interview.

Thanks

I'll share different learnings out of our Snowflake World. This is a kind of a post-mortem, and I already heard, that we're not alone with this case. Tell me your experiences, please.

Let's start. Here's the story:

Summary: A tightly configured Snowflake Resource Monitor (25 credits/month) shut down a CDC replication pipeline (OpenFlow PostgreSQL Connector), caused 4 days of missing data (over a weekend, temporary) and generated cloud services costs that far, far exceeded the monitor's own quota. The exact opposite of what the monitor was supposed to prevent.

Background

• OpenFlow PostgreSQL CDC Connector replicates data from a PostgreSQL database into Snowflake
• Warehouse: X-Small, dedicated to the connector, normal consumption ~1 credit/day
• Resource Monitor: Monthly quota of 25 credits, suspend action at 85%

What Happened

Step 1: Runtime Upgrade Without Adjusting the Resource Monitor

The OpenFlow runtime had recently been upgraded from Small to Medium to handle increased data volumes. This roughly doubled the connector's baseline credit consumption, but the resource monitor's monthly quota of 25 credits was not adjusted to match. The quota had been adequate for the original runtime size.

Within days, the resource monitor reached its 85% threshold (~21 of 25 credits). The connector's warehouse was suspended. The connector itself was operating normally. The only issue was a resource monitor that no longer fit the runtime's actual needs.

Step 2: The Connector Keeps Retrying

The OpenFlow connector had no way of knowing that the warehouse was suspended. On every merge cycle, it attempted to merge journal data into the destination tables:

Warehouse 'MY_WH' cannot be resumed because resource monitor 
'MY_WH_MONTHLY' has exceeded its quota.

Each rejected query consumed no warehouse credits but still incurred cloud services costs. The connector performed thousands of retries per table, up to 10,000 per table across all tables of this processor.

Step 3: Costs Explode

Over a roughly 39-hour weekend window, the connector submitted over a million rejected queries. Each one incurred a small cloud services charge. The cumulative cloud services cost ended up far, far exceeding the monitor's entire monthly quota of 25 credits. A cost control mechanism designed to save credits had instead amplified the spend far beyond what normal operations would ever have consumed.

Step 4: Tables Fall Into FAILED Status

After exhausting the maximum retries (default 10,000 per table), the connector marked the affected tables as FAILED without any communication to us.

The CDC pipeline broke down. New data from PostgreSQL stopped arriving in Snowflake entirely.

Step 5: 4 Days Without Fresh Data

The warehouse suspension happened on a Friday. The OpenFlow UI showed no obvious errors at the processor group level, and the connector did not fire any alerts. There was no indication that data had stopped flowing unless you checked the destination tables directly. Because of this, the issue went unnoticed over the weekend and was only discovered on Monday when the team noticed stale data in downstream reports. We learned something, we have freshness monitors for critical entities now.

For 4 days, all new transactional data, customer changes and catalog updates were missing from Snowflake. Downstream processes like business views, reporting dashboards and AI agents operated on stale data without anyone being aware.

Root Cause

A resource monitor can suspend a warehouse, but it cannot stop the clients that continue submitting queries. Cloud services credits (query parsing, access control, metadata operations) are incurred even on rejected queries and count toward the monitor's usage. Yet the monitor has no way to cap them.

The core problem is a gap between two systems:

1. Resource Monitor assumes: "I suspended the warehouse, so the limit is enforced"
2. OpenFlow Connector assumes: "The query failed, I need to retry"

Neither system is aware of the other's behavior.

Resolution

Immediate Fix: Re-Snapshot All FAILED Tables

1. In the OpenFlow UI (Snowsight > Ingestion > Openflow), all affected tables were added to the Re-snapshot Table Exclusions parameter
2. Waited until the tables disappeared from the Table State Store
3. Removed the tables from the exclusions again, which triggers an automatic re-snapshot
4. The connector creates zero-copy clone archives (*_ARCHIVE_<timestamp>) of the old data, truncates the destination tables and loads a fresh snapshot from PostgreSQL

The re-snapshot of all tables, including tables with tens of millions of rows, took several hours.

Preventive Measures

1. Size the resource monitor generously or let it got for a separted OPENFLOW_WH. A CDC connector needs headroom. A limit barely above normal consumption inevitably leads to suspensions that cost more than the credits they were supposed to save.
2. Notify instead of Suspend. Resource monitors can use NOTIFY instead of SUSPEND. For a critical CDC connector, an alert is better than a hard stop.
3. Reduce merge frequency. The cron schedule controls how often the connector attempts merges. A lower frequency (if possible from the business requirements) dramatically reduces retry load when a warehouse is suspended.
4. Account-level budget as early warning. An account-level budget can alert when total spend (including cloud services) crosses a threshold.

What Should Be Improved (Product Level) or hello Snowflake PM-Team

This incident exposed gaps that neither the customer nor the current product configuration can fully address. The following improvements would prevent this class of failure.

1. Warehouse-Aware Retry Logic

The connector should detect that the assigned warehouse is unavailable due to a resource monitor suspension. The error message is distinct and unambiguous. Instead of retrying blindly, it should automatically pause the processor group. A simple circuit breaker that stops retrying after N consecutive "resource monitor exceeded" errors, pauses the processors and resumes when the warehouse becomes available would have prevented the entire retry storm and the resulting cloud services costs.

2. Backoff Strategy for Non-Transient Errors

A suspended warehouse is not a transient network glitch. The connector should distinguish between transient errors (connection timeout, HTTP 503) and persistent infrastructure errors (resource monitor quota exceeded, warehouse dropped). Transient errors warrant aggressive retries. Persistent errors should trigger exponential backoff or a full stop.

3. Alerting on Retry Storms

The connector currently logs each failed retry but does not raise a distinct alert when a table enters a sustained retry loop or fail state at the end. A notification (email, webhook) after a configurable number of consecutive failures would give operators a chance to intervene before costs accumulate.

4. Sensible Retry Defaults

The retry limit per table is technically configurable as a parameter on the processor group, but it defaults to 10,000. For non-transient errors like a suspended warehouse, that default is far too high. A lower default or a separate, smaller limit for infrastructure errors (as opposed to transient network issues) would significantly limit the blast radius.

5. Resource Monitor Cloud Services Cap

On the Snowflake platform side, resource monitors currently cannot limit cloud services costs. A rejected query still incurs cloud services credits, and the monitor counts them toward its total but cannot act on them. Extending resource monitors to cap or alert on cloud services consumption would close this gap at the platform level.

Lessons Learned

• A resource monitor is not a cost cap. It can stop warehouse compute, but it cannot prevent cloud services costs from rejected queries. Relying on it as a hard ceiling is a false sense of security.
• Factor in connector retry behavior. Every managed service that runs against Snowflake (OpenFlow, Fivetran, Airbyte, etc.) has retry logic. A suspended warehouse leads to retry storms, not silence.
• Cost management must not blindly kill critical pipelines. When a pipeline delivers business-critical data, a hard suspend is counterproductive. The cost of missing data far exceeds the credits saved.
• The most expensive cost-saving measure is the one that backfires. A 25-credit monthly limit was meant to save money. The result: cloud services costs exceeding unlimited, a multi-hour re-snapshot and 4 days of missing data.
• There is a great Snowflake support team available: Ask them for help, insights or credit refunds in such cases. You'll find a solution together.

I have a dynamic table that builds on a XS Warehouse and takes only 57 seconds. However, when I add a new field, the entire table rebuilds and it's roughly 3 billion rows. There's been a couple of times me and my team members forgot to manually change the warehouse associated to the dynamic table to a XL warehouse. Because of that, the build took about 4 hours on XS. Does anyone have a better way to keep track to change the table size when rebuilding to an XL?

Should I create a worksheet and have ALTER <dynamic table> SET WAREHOUSE = "XL_WH' at the top, and have a comment associated wth it?

If you run dbt on Snowflake, you have probably seen this. A model passes every test and still scans more than it needs to.

Profile Query in dbt Power User reviews the SQL in one click. It flags SELECT * in a CTE, aggregation before a join and divide-by-zero risk.

Here is a 4-minute demo: https://youtu.be/uMptd4t_mGI

This is installable for VS Code or Cursor and used by over 35000 developers!

Has anyone seen an increase in QH compile time? Takes 2 minutes sometimes to compile a QH script.

PM here from Snowflake Postgres.

I was the chief product office of the Crunchy Data team that was acquired just before Summit over a year ago. The top ask from most early customers was easing getting their Postgres data into Snowflake. We were already hard at work on it from day one, and even some of the foundations of it with pg_lake date back to over 3 years go.

Today that capability to mirror your data from Postgres to Snowflake is going GA. The blog post has more details, but happy to field any questions folks may have about how it works, the engineering behind it, or just Postgres in general.

Blog post with more details at: https://www.snowflake.com/en/blog/data-mirroring-ga-snowflake-postgres/

I’ve been wondering why we keep comparing Databricks and Snowflake primarily through feature checklists, when their architectural DNA has been fundamentally different from the beginning.
Snowflake started as a cloud data warehouse, primarily optimized for SQL analytics and BI workloads. Over time, it has been expanding into data engineering, ML, AI, and beyond.
Databricks, on the other hand, started from general-purpose distributed data processing with Spark, with data engineering and ML at its core. It progressively built a broader platform around those foundations, expanding into SQL warehousing, BI, governance, and AI.

And I think that difference in DNA matters much more than we realize.
It’s one thing to build new capabilities on top of a flexible data processing foundation. It’s another to extend a platform originally optimized for a specific category of workloads into an increasingly diverse ecosystem.
Governance is another interesting aspect. With Unity Catalog, Databricks has developed a common governance layer spanning data, ML models, functions, and AI assets, helping these capabilities fit into a coherent ecosystem.
Snowflake has strong governance capabilities too, but I wonder whether its warehouse-centric origins introduce additional architectural complexity as the platform expands.

That’s where my Swiss Army knife analogy comes from.
Databricks feels like a Swiss Army knife whose capabilities are increasingly integrated into a common architecture.
Snowflake sometimes feels like an excellent pocketknife that’s progressively getting more and more attachments. Some are genuinely impressive. Others feel a bit forced.
Don’t get me wrong: Snowflake is an excellent platform, particularly for SQL-centric workloads, and both platforms have evolved significantly.

But having similar features doesn’t necessarily mean having equally suitable foundations for every workload.
Are we comparing two equivalent platforms, or two fundamentally different architectural philosophies?
Curious to hear your thoughts, especially from people working extensively with both.

My company currently has JSON data landing in a "staging" table in Snowflake nightly at 11 pm. There's dynamic tables that transform the data from a variant column into a structured table. Currently we have the dynamic tables set up on an hourly lag even though data only comes in once a day. The reason being is there are multiple scheduled tasks that refers to these dynamic tables after 11 pm and we do not want the lag to be such a wide range incase the dynamic tables have not refreshed, but these tasks run and will not capture the latest data in the "staging" tables.

Should I change the set up? Is it costing the company Snowflake credits by having the dynamic table checked hourly even though we know data will only come in once a day? Is there no way to schedule a refresh on a specific time for a dynamic table?