Novidades no Snowflake: Verão 2025

Nova barra lateral (Preview, em rollout agora)

O Snowflake está liberando uma barra de navegação lateral esquerda reorganizada. Algumas contas já receberam, outras vão migrar em fases. Pelo que tenho visto, a maioria das contas já está com ela. Os grupos do menu ficaram mais limpos e refletem melhor como os times trabalham. Para mim, levou um tempinho até me acostumar. Demorei alguns segundos para achar "databases" e "query history", mas no geral adorei o novo layout!

Layout:

• Shortcuts: fixe até três páginas para acesso rápido. Arraste para reordenar.
• Work with data: Projects, Ingestion, Transformation (dbt, Task History, Dynamic Tables), AI & ML, Monitoring (query history! A visualização gráfica da sua event table também está aqui), Marketplace.
• Horizon Catalog: Catalog (databases ficam aqui!), Data sharing, Governance & security.
• Manage: Compute e Admin.

Veja como fixar e desafixar shortcuts:

Esta captura de tela, tirada da documentação do Snowflake, mostra a barra lateral nova e a antiga lado a lado.

A propósito, se você ainda não testou a nova busca global, precisa experimentar! Ela pesquisa em databases, marketplace, documentação ou praticamente qualquer coisa no Snowflake para encontrar suas palavras-chave. Achei muito útil para achar o que procuro rapidinho.

Use o Snowsight para criar uma Semantic View (Public Preview)

Você pode criar e gerenciar Semantic Views direto no Snowsight pelo explorador de objetos do database ou pela página do Cortex Analyst. Dá para usar o assistente (wizard) ou fazer upload de YAML.

• Pontos de partida:
  • Barra lateral antiga: Data → Databases → Selecione um schema → Create → Semantic View, ou AI & ML → Cortex Analyst → Create / Upload YAML.
  • Barra lateral nova: Horizon Catalog → Catalog → Database → selecione um schema → create, Semantic View
  • Ou em AI & ML → Cortex Analyst

Achei super fácil criar uma nova Semantic View. As capturas de tela abaixo descrevem o processo.

Passo 1: Navegue até um Schema e clique em "Create". A imagem abaixo mostra a nova barra lateral; databases e schemas agora ficam em "Horizon Catalog".

Passo 2: Preencha as páginas do formulário

Veja como fazer a mesma coisa pelo menu do Cortex Analyst:

Observação: consultar semantic views com SQL também está em Preview. Confira a documentação para mais informações.

Dynamic Tables: leitura de Iceberg gerenciado externamente (GA)

As dynamic tables agora conseguem ler diretamente de tabelas Iceberg gerenciadas por um catálogo externo. Esse é um avanço relevante nos recursos de pipeline de dados do Snowflake para quem trabalha com Iceberg. Mais informações na documentação.

Tipos estruturados para tabelas padrão (GA)

Outras plataformas de dados, como Big Query e Databricks, oferecem há tempos tipos de dados estruturados (struct, array, record), enquanto o Snowflake só tinha o tipo variant para esses casos de uso.

Agora você pode definir ARRAY, OBJECT e MAP como colunas estruturadas em tabelas Snowflake comuns, com até 1.000 subcolunas por coluna. Por enquanto, tipos estruturados não são suportados em dynamic tables, hybrid tables ou external tables. Veja a documentação para mais detalhes.

Pré-clusterização para Snowpipe Streaming (Preview)

O Snowpipe Streaming pode pré-clusterizar linhas durante a ingestão para que os dados cheguem ordenados pelas suas clustering keys, melhorando o desempenho das consultas em hot tables e reduzindo a carga do automatic clustering. Ainda não testamos, mas isso provavelmente vai virar uma tática de economia para clientes com gasto alto em automatic clustering.

Ative a pré-clusterização na definição do COPY com CLUSTER_AT_INGEST_TIME=TRUE; sua tabela de destino já precisa ter cluster keys.

CREATE OR REPLACE PIPE TEST_PRECLUSTERED_PIPE
AS
    COPY INTO TEST_PRECLUSTERED_TABLE (num) FROM (
            SELECT $1:num::number as num FROM TABLE(
                DATA_SOURCE(
                    TYPE => 'STREAMING')
        ))
        CLUSTER_AT_INGEST_TIME=TRUE;

Comando COPY FILES (GA)

O COPY FILES move objetos de um stage para outro. Um caso de uso real é mover arquivos de uma pasta "unprocessed" para uma pasta "processed".

Nesse cenário, você pode definir bucket policies (fora do Snowflake) para garantir que a pasta unprocessed seja limpa depois de um certo tempo, sem precisar de código extra para gerenciar o ciclo de vida dos dados.

Por exemplo, dá para criar uma policy que apaga os dados de unprocessed após 30 dias, enquanto a policy nos dados processed arquiva tudo no Glacier após 60 dias. Esse tipo de estratégia reduz a duplicação de dados e os custos de armazenamento fora do Snowflake.

Executar tasks como outro usuário: EXECUTE AS USER + IMPERSONATE (GA)

As tasks podem rodar com os privilégios de um usuário específico via EXECUTE AS USER, desde que a role dona da task tenha IMPERSONATE sobre esse usuário. Isso é útil quando políticas ou sistemas downstream dependem da identidade do usuário para coisas como row access ou masking, e facilita identificar quem uma task realmente representou na hora de revisar os logs.

Abaixo, um exemplo simplificado para mostrar a nova funcionalidade. O exemplo assume que os usuários e roles já existem. Veja a documentação do Snowflake para um exemplo completo, incluindo criação de usuários, roles, warehouses, task grants etc.

-- grant impersonate.  Nova funcionalidade!
GRANT IMPERSONATE ON USER task_user TO ROLE task_role;

USE ROLE task_owner;

-- executa a task como outro usuário
CREATE TASK team_task
  SCHEDULE='12 HOURS'
  EXECUTE AS USER task_user
  AS SELECT 1;

O novo modelo de preços do Snowpipe anunciado no Summit: agora em GA para Business Critical e VPS

No nosso Summit Recap já comentamos que o novo modelo de preços do Snowpipe seria um ganho para os clientes. O modelo antigo tinha dois componentes: por segundo por core e por 1.000 arquivos. O novo é simplificado: um valor fixo de créditos por GB ingerido.

Isso saiu do conceito e chegou ao GA para clientes Business Critical e VPS, e em breve será liberado para clientes Standard e Enterprise.

Para entender todos os detalhes, vale mesmo revisar a tabela de consumo de créditos e a documentação de custos do Snowpipe.

Snowpark Connect for Spark e Snowpark Submit (Preview)

Resumindo: agora você pode rodar jobs do Apache Spark direto no Snowflake sem reescrever código. Isso inclui Spark DataFrame, SQL e UDFs. Também dá para submeter jobs não interativos de forma assíncrona via Snowpark Submit.

Esses recursos são uma ponte pragmática para times de Spark que estão migrando para o Snowflake e não querem reescrever código Spark em APIs Snowpark.

Você pode desenvolver em ferramentas que já conhece, como Jupyter Notebooks ou Snowflake Notebooks. Veja a documentação para mais detalhes.

UDFs com Snowflake Scripting (GA)

Agora você pode usar a lógica de Scripting do Snowflake em UDFs SQL e chamá-las inline nas queries, e não só via CALL como acontece com stored procedures. Excelente para pequenos helpers procedurais ou funções SQL customizadas que você quer reaproveitar em SELECT/INSERT.

O Snowflake Scripting é uma linguagem de scripting SQL poderosa. Os detalhes completos da nova funcionalidade de UDF estão aqui.

Vale destacar que isso não funciona com cursors (declare … c1 cursor for select foo from bar). Essa limitação acaba sendo um benefício, porque lógica baseada em linhas como cursors é uma péssima ideia em funções SQL.

Dynamic tables: UNION em refresh incremental (GA)

À medida que os clientes vão adotando os recursos nativos de pipeline de dados do Snowflake, a empresa fecha uma lacuna óbvia e irritante: dynamic tables incrementais agora suportam UNION (distinct) em queries de refresh, ampliando os tipos de merges multi-origem que você pode rodar sem cair em full refresh. Os demais operadores de conjunto (por exemplo, minus, except, intersect) continuam sem suporte no modo incremental.

CREATE DYNAMIC TABLE my_dynamic_table
 TARGET_LAG = DOWNSTREAM
 AS
 SELECT * from foo
 -- não precisa mais de union all
 union
 select * from bar;

Dica para quem está começando em SQL: é considerada boa prática preferir union all a union, porque union força um distinct, o que deixa a execução da consulta mais lenta. Então só use essa nova funcionalidade se você realmente precisar que o union seja distinct.

Até a presente data, a documentação do Snowflake ainda não foi atualizada para incluir o suporte ao operador union, mas o recurso já está liberado. 🧐

Eventos de monitoramento para o Snowpipe, além de eventos de auto-refresh do Iceberg (GA)

O Snowpipe agora publica eventos detalhados de ingestão na Event Table ativa. Dá para ver quando um pipe muda de estado, acompanhar o progresso por arquivo e revisar resumos periódicos da atividade de ingestão. Além disso, o Snowflake também emite eventos sempre que uma tabela Iceberg gerenciada externamente é atualizada automaticamente.

O resultado é que você consegue observar todo o ciclo de vida da ingestão, dos arquivos em stage chegando ao Snowpipe até as tabelas Iceberg downstream sendo mantidas atualizadas, tudo em um único lugar. Isso fecha uma lacuna de visibilidade que existia há muito tempo. Na prática, deve facilitar bastante resolver problemas de arquivos travados ou refreshes atrasados, além de abrir espaço para alertas mais afinados em torno dos SLAs do pipeline de dados. Acho que essa é uma daquelas funcionalidades de "qualidade de vida" que à primeira vista não parecem chamativas, mas times rodando pipelines de ingestão em produção vão valorizar de imediato.

Veja mais informações sobre o recurso.

Defina um tamanho de arquivo alvo para tabelas Iceberg (Preview)

Agora você pode definir um tamanho alvo para o arquivo Parquet ao criar ou alterar uma tabela Iceberg. Isso dá mais controle sobre como os dados são escritos e pode melhorar o desempenho quando esses arquivos forem lidos por engines como Spark ou Trino.

É especialmente útil em setups multi-engine, em que o tamanho do arquivo pode fazer toda a diferença na eficiência das consultas. Arquivos menores se adequam a consultas rápidas e granulares, enquanto os maiores reduzem o overhead em scans grandes. Vejo isso como um passo prático que torna o Snowflake mais flexível para uso em lakehouse híbrido.

Aqui está um exemplo de como criar ou alterar uma tabela Iceberg usando essa nova funcionalidade:

CREATE ICEBERG TABLE my_iceberg_table (
  amount INT,
  name STRING
)
  CATALOG = 'SNOWFLAKE'
  EXTERNAL_VOLUME = 'my_external_volume'
  BASE_LOCATION = 'my_iceberg_table'
  TARGET_FILE_SIZE = '64MB'; -- NOVO!

ALTER ICEBERG TABLE my_iceberg_table
SET TARGET_FILE_SIZE = '128MB';

ALTER LISTING: adicionar/remover targets de forma mais simples (GA)

Provedores do Marketplace agora podem adicionar ou remover listing targets com um manifesto parcial, em vez de reenviar o conjunto completo de targets. Isso reduz a complexidade da automação ao gerenciar muitas contas, roles ou organizações.

Facts e metrics privados em semantic views (General Availability)

Você pode marcar facts e metrics como PRIVATE ao definir uma semantic view. Itens privados podem ser usados em cálculos dentro da view, mas não podem ser consultados diretamente nem usados em filtros. Eles continuam aparecendo em DESCRIBE SEMANTIC VIEW e GET_DDL, o que ajuda na descoberta e em auditorias. É útil quando você quer expor métricas limpas e prontas para o negócio na superfície, mantendo facts auxiliares e métricas intermediárias escondidas. Minha opinião: era uma lacuna que eu nem tinha percebido, mas que deixa as semantic views muito mais prontas para produção em cenários de analytics governado.

CREATE SEMANTIC VIEW my_sales_view
  TABLES (
    orders AS my_db.my_schema.orders PRIMARY KEY (order_id)
  )
  FACTS (
	  -- Nova funcionalidade
    PRIVATE adjustment_factor AS AVG(orders.adjustment)
  )
  METRICS (
    total_revenue AS SUM(orders.revenue),
    -- Nova funcionalidade
    PRIVATE adjusted_revenue AS SUM(orders.revenue + adjustment_factor)
  );

Função AI_EXTRACT (Preview)

O AI_EXTRACT extrai campos estruturados a partir de entradas não estruturadas. Funciona com strings ou entradas do tipo FILE, e você define o formato da resposta com prompts simples ou pares nome-prompt. Pense em notas fiscais, contratos, prontuários médicos ou PDFs de marketing — tudo extraído diretamente dentro do Snowflake. Isso reduz o vai e volta com serviços externos e simplifica o caminho até dados estruturados e prontos para uso. É promissor para times que já centralizam dados no Snowflake, mas trate como qualquer recurso de IA em preview. Minha abordagem seria começar com um conjunto de testes rotulado para ver como ele se comporta. Pense em quais guardrails você quer adicionar antes de plugá-lo em pipelines críticos!

Exemplos:

-- Sintaxe:
AI_EXTRACT( <text>, <responseFormat> )

-- exemplo que especifica saída estruturada
AI_EXTRACT( <'coluna sql contendo texto não estruturado'>,
['address': 'City, street, ZIP', 'name': 'First and last name'] )

-- outro exemplo em que a saída é em linguagem natural
-- aqui extraímos de um arquivo em vez de uma coluna
AI_EXTRACT( <'um arquivo pdf no Snowflake Stage'>,
['me dê endereço e primeiro e último nome' );\
```\
\
### Modo layout do AI Parse Document (GA)\
\
O modo layout do [`AI_PARSE_DOCUMENT`](https://docs.snowflake.com/en/user-guide/snowflake-cortex/parse-document#ai-parse-document) é uma nova funcionalidade em GA que substitui a função `SNOWFLAKE.CORTEX.PARSE_DOCUMENT`. Ela extrai o layout de um documento em Markdown, preservando o fluxo do texto, as tabelas e a estrutura. Simplificando: de PDF (ou similar) para Markdown! 🥳 Isso te dá uma forma intermediária limpa para chunking, RAG ou parsing downstream. Parece que esse parsing com consciência de layout é a base para uma IA de documentos confiável. Também imagino combiná-lo com `AI_EXTRACT` para ir de arquivos brutos a linhas estruturadas com menos etapas.\
\

\

Processamento distribuído no Snowflake ML: Many Model Training e Distributed Partition Function (General Availability)\

O Snowflake ML agora suporta dois padrões distribuídos. O Many Model Training (MMT) treina modelos separados por partição de um Snowpark DataFrame em paralelo. A Distributed Partition Function (DPF) executa sua função Python em partições, em um ou mais nós de um compute pool, com armazenamento de artefatos e acompanhamento de progresso já feitos pra você. Isso elimina muito do trabalho de orquestração ao escalar horizontalmente na plataforma que você já usa.

Se você quiser saber mais, Treinar modelos em partições de dados e Processar dados com lógica customizada entre partições estão muito bem documentados.
\

\

Data Metric Function: ACCEPTED_VALUES (GA)\

O ACCEPTED_VALUES é uma DMF de sistema que valida se os valores de uma coluna atendem a uma expressão booleana e retorna a contagem de linhas que não atendem. Você a associa a uma tabela ou view de forma agendada ou executa de modo ad hoc com SYSTEM$DATA_METRIC_SCAN.

É uma forma de baixo esforço e alto valor para detectar problemas simples de conformidade, como enums e conjuntos de códigos, sem precisar de SQL customizado.
\

1-- sintaxe\
\
2SNOWFLAKE.CORE.ACCEPTED_VALUES ON ( <column>, <lambda-expression> )\
\
3\
\
4-- exemplo\
\
5ALTER TABLE orders\
\
6  ADD DATA METRIC FUNCTION SNOWFLAKE.CORE.ACCEPTED_VALUES\
\
7    ON (\
\
8      order_status,\
\
9      order_status -> order_status IN ('Pending', 'Shipped', 'Delivered', 'Returned')\
\
10    );\
\
11\
\
12 CALL SYSTEM$DATA_METRIC_SCAN('orders');\
\
13 -- isso retornará todas as DMFs da tabela orders\
```\
\
### Atualizações do Snowflake Data Clean Rooms (GA)\
\
Um data clean room é um ambiente seguro em que várias partes podem analisar datasets combinados sem acessar diretamente os registros brutos umas das outras. Isso acontece por meio de controles e políticas rígidos de consulta, que só permitem saídas aprovadas, como agregados ou resultados anonimizados — nunca dados em nível de linha.\
\
O Snowflake liberou 4 atualizações de data clean rooms no mês passado. São basicamente melhorias de qualidade de vida que removem fricções no uso dos data clean rooms.\
\
- **Fluxo simplificado para compartilhamento cross-region**: provedores não precisam mais chamar `request_laf_cleanroom_requests` e `mount_laf_cleanroom_requests_share` para aceitar solicitações de consumidores em outra região. Agora basta usar `provider.mount_request_logs_for_all_consumers`. Isso aparece no [guia do desenvolvedor](https://docs.snowflake.com/en/user-guide/cleanrooms/activation?utm_source=chatgpt.com) em "Implementing activation in your clean room".\
- **Instalação simplificada**: o Snowflake agora cria e verifica automaticamente o service user necessário para clean rooms, ou reutiliza um existente, em vez de exigir que os usuários façam isso manualmente. Ou seja, menos passos de configuração antes de começar a usar clean rooms de verdade.\
- **Testes com conta única**: agora você pode usar uma única conta Snowflake atuando como provedor e consumidor em um clean room de teste. Ótimo para ambientes de dev/test, permitindo criar e validar templates de clean room sem precisar provisionar contas separadas. A página de tutoriais e samples mostra isso na prática (" [Basic UI tutorial, single account](https://docs.snowflake.com/en/user-guide/cleanrooms/tutorials-and-samples?utm_source=chatgpt.com)"). Veja a [documentação](https://docs.snowflake.com/en/user-guide/cleanrooms/developer-introduction#label-dcr-self-share-for-developers) para uma leitura mais rápida.\
- **Taxas de refresh configuráveis para Cross-Cloud Auto-Fulfillment**: por padrão, o refresh de dados entre contas de provedor e consumidor em diferentes clouds ou regiões agora é a cada 30 minutos (antes era a cada 24 horas). E você pode configurar essa taxa. [Veja a documentação](https://docs.snowflake.com/en/user-guide/cleanrooms/provider.html#dcr-provider-set-laf-dcr-refresh-schedule).\
\
### Snapshots Write Once, Read Many (WORM) (Preview)\
\
Os WORM [Snapshots](https://docs.snowflake.com/en/user-guide/snapshots) são backups point-in-time **imutáveis** de tabelas, schemas ou databases. Eles usam snapshot sets e policies opcionais de snapshot para agendamento e expiração. **Retention lock** e **legal holds** adicionam proteção contra exclusão, com o retention lock pensado para garantias robustas de compliance. Nem mesmo o accountadmin pode dropar essas tabelas, o que oferece forte proteção contra credenciais comprometidas e ransomware. Os WORM Snapshots estão disponíveis em todas as edições, com retention lock e legal holds para Business Critical e superior.\
\
É um controle prático para resiliência contra ransomware e retenção regulatória, indo além do Time Travel. A funcionalidade parece promissora para higiene de backup, mas ainda está em preview, então teste os caminhos de restore e planeje o armazenamento antes de apostar no retention lock.\
\

\

Org profiles (General Availability)\

Agora dá para criar e gerenciar perfis de organização no Snowsight, atribuir quais contas e roles podem publicar sob um perfil e dar identidade visual a listagens internas com um avatar de perfil e referência de URL. Isso reforça a confiança dentro do Internal Marketplace e elimina um monte de SQL avulso na configuração. Faz com que organizações grandes pareçam mais organizadas e dá aos consumidores uma procedência mais clara para produtos de dados internos.

\

Ativação self-service do Tri-Secret Secure (General Availability)\

Relembrando do seu treinamento Snowflake, o Tri-Secret Secure é a abordagem de criptografia do Snowflake em que três chaves estão envolvidas: a chave do próprio Snowflake, a do provedor de cloud e uma chave gerenciada pelo cliente. Os dados só podem ser descriptografados se as três estiverem disponíveis, o que dá ao cliente controle direto para suspender o acesso simplesmente desabilitando a própria chave. Está disponível para Business Critical e VPS.

Usando a nova funcionalidade de Self Service Activation, ACCOUNTADMINs podem ativar o Tri-Secret Secure por conta própria via funções de sistema, gerenciar a chave gerenciada pelo cliente e até desativá-la, se necessário. Isso elimina o ciclo com o suporte e faz com que controles fortes de criptografia virem parte padrão da higiene da conta, e não um projeto especial que depende do suporte ao cliente.
\

Query Insights: desempenho e otimização de joins (Public Preview)\

Contexto:

O Query Insights é uma funcionalidade nativa relativamente nova que mostra automaticamente descobertas sobre suas consultas, como joins ineficientes ou filtros ausentes. Em vez de ficar garimpando profiles brutos, você recebe dicas legíveis que apontam para correções que melhoram o desempenho e reduzem custos.

Os insights podem ser encontrados no Snowsight Query History → Query Profile, ou consultando a view snowflake.account_usage.query_insights. Usar uma ferramenta de terceiros como o SELECT oferece aos usuários uma observabilidade muito melhor sobre query insights, em uma UI feita sob medida para isso.


Nova funcionalidade:

O Query Insights adiciona novas descobertas sobre erros em joins e ganhos de otimização, e você pode visualizá-las no Snowsight ou consultando a view QUERY_INSIGHTS. As dicas apontam padrões como condições de join ausentes, joins explosivos, falta de filtros, uso de search optimization e spillage, permitindo corrigir a causa raiz mais rápido. É bem útil para triagem, mesmo que você ainda se apoie no Query Profile para análises mais profundas.
\

Semantic views: listar dimensões e métricas em qualquer escopo (GA)\

Você pode inventariar sua camada semântica com SHOW SEMANTIC DIMENSIONS e SHOW SEMANTIC METRICS em qualquer escopo: view, schema, database ou conta, e ainda listar quais dimensões são válidas para uma métrica específica. Isso ajuda a auditar modelos, verificar grão e relacionamentos e manter os times alinhados sobre o que de fato está disponível. É um recurso pequeno, mas muito bem-vindo para quem está em funções de admin e depende dos comandos show para entender a governança.
\

Aqui vai uma lista rápida de outras atualizações que merecem destaque:
\

• Multi-Node ML jobs - Preview\
• Create Index com suporte a "Include Columns" - GA\
• Consistency Secret agora opcional em generate_synthetic_data - GA\
• Consulta a Semantic Views passou de Preview para GA\
• A função SEARCH_IP agora suporta busca por endereços IPv6 - GA\
• E-mails do Trust Center passaram de Preview para GA Novo Stage Volume para Snowpark Container Services - Preview\
• Microsoft Power Apps Connector - GA
  \

Uau, quanta novidade em dois meses! Avisa a gente se precisar de orientação sobre alguma delas.



Jeff é Consultor de Dados e Analytics com mais de 15 anos de experiência em automatizar insights e usar dados para conduzir processos de negócio. Do ponto de vista tecnológico, é especialista em Snowflake + dbt + Tableau. Em termos de áreas de atuação, tem experiência em Utilidades Públicas, Ensaios Clínicos, Editorial, CPG e Manufatura. Fale com ele quando quiser: [email protected].\