Arquitetura do Snowflake explicada e para que ele serve

A arquitetura do Snowflake divide uma plataforma de dados em três camadas que escalam de forma independente: armazenamento, computação (os chamados virtual warehouses) e uma camada de cloud services que coordena tudo. As empresas usam o Snowflake como data warehouse em nuvem para relatórios e análises e, cada vez mais, como um lugar para compartilhar dados, rodar Python e construir IA sobre dados governados.

Essa única escolha de desenho, manter armazenamento e computação separados, explica a maior parte do que o Snowflake faz bem e a maior parte do que ele custa.

Trabalhei com Snowflake em programas de plataforma de dados na indústria e no setor de defesa. Um padrão que vejo com frequência: os líderes o compram pelas análises e depois descobrem que as decisões de arquitetura (quantos warehouses, qual edição, onde os dados ficam) decidem a conta e a posição de compliance. Este guia é para o CIO, o CDO ou o arquiteto que precisa entender essas decisões antes de assinar.

O Snowflake é uma plataforma de dados totalmente gerenciada que roda na Amazon Web Services, no Microsoft Azure e no Google Cloud. Você não o instala, não aplica patches nem ajusta índices. Você carrega os dados, escreve SQL (ou Python) e paga armazenamento e computação separadamente.

O Snowflake descreve seu desenho como um híbrido das arquiteturas shared-disk e shared-nothing: um repositório central de dados, consultado por clusters de computação independentes. Um fato importa cedo para compradores da área de defesa: segundo o próprio guia de conceitos-chave e arquitetura do Snowflake, ele não pode ser instalado em infraestrutura local ou de nuvem privada.

Esta é a pilha, de baixo para cima.

1. 03Cloud servicesSegurança, controle de acesso, metadados, otimização de consultas e transações
2. 02ComputaçãoVirtual warehouses: clusters independentes que rodam SQL e Python, cobrados em créditos enquanto estão ligados
3. 01ArmazenamentoMicro-partições colunares e comprimidas em object storage na nuvem, cobradas por terabyte

Armazenamento

Quando você carrega dados, o Snowflake os reorganiza em um formato colunar e comprimido e os armazena em object storage na nuvem. Ele divide cada tabela em micro-partições, cada uma com entre 50 MB e 500 MB de dados não comprimidos. O Snowflake registra metadados de cada uma, como o intervalo de valores em cada coluna.

Esses metadados são a parte inteligente. Uma consulta filtrada pelas ordens de produção do mês passado pula toda micro-partição cujo intervalo de datas não pode corresponder.

Isso se chama pruning, e é por isso que o Snowflake tem bom desempenho sem índices. Também significa que a forma como os dados chegam (ordenados por data ou por fábrica, ou aleatoriamente) afeta o custo em tabelas muito grandes.

Computação: virtual warehouses

Um virtual warehouse é um cluster de computação que roda consultas e código. Cada um é independente. Seus relatórios de fechamento mensal de finanças podem rodar em um warehouse enquanto a ciência de dados roda jobs pesados em outro, e nenhum deixa o outro mais lento.

Os warehouses vêm em tamanhos de camiseta e só consomem créditos enquanto estão ligados. Eles podem ser suspensos automaticamente quando ficam ociosos. Tamanhos maiores tornam consultas pesadas individuais mais rápidas.

Mais clusters atendem mais usuários ao mesmo tempo, e é isso que os warehouses multi-cluster fazem: na edição Enterprise e acima, um warehouse pode acrescentar clusters automaticamente quando as consultas começam a formar fila e removê-los quando a carga cai. O Snowflake é explícito: o multi-cluster ajuda a concorrência, não uma única consulta lenta. Para isso, você aumenta o tamanho.

Meu guia de preços sobre créditos do Snowflake e o que move a conta cobre o lado dos custos em detalhe.

Cloud services

A camada superior cuida de autenticação, controle de acesso, metadados, otimização de consultas e transações. Time Travel e cloning são, em grande parte, operações de metadados, então é essa camada que os torna possíveis. Você raramente pensa nela, e é exatamente essa a ideia.

Os recursos interessantes não são acessórios. Eles decorrem do desenho de armazenamento e de metadados.

1. Time Travel. Você pode consultar, clonar ou restaurar dados como estavam em um momento do passado. A edição Standard guarda 1 dia. A Enterprise e as superiores podem guardar até 90 dias para tabelas permanentes, como descreve a documentação do Time Travel.
2. Fail-safe. Quando o Time Travel expira, os dados das tabelas permanentes passam para um período de Fail-safe de 7 dias. Só o Snowflake consegue recuperá-los. Trate isso como recuperação de desastres, não como um backup que você controla.
3. Zero-copy cloning. Um clone de uma tabela, schema ou banco de dados não usa armazenamento extra quando é criado, porque aponta para as mesmas micro-partições. Você paga apenas pelos dados que mudam depois. É assim que as equipes sobem ambientes de teste em tamanho real em minutos.
4. Secure data sharing. Um provedor compartilha tabelas vivas com outra conta Snowflake, sem copiar dados. O consumidor paga apenas pela computação que usa para consultar. Os shares diretos funcionam dentro de uma região; o compartilhamento entre regiões passa por listings com auto-fulfilment.
5. Snowflake Marketplace. Os listings permitem publicar data products para parceiros específicos ou publicamente, incluindo dados de terceiros, como clima ou índices de mercado.
6. Snowpark. Bibliotecas para Python, Java e Scala que levam o processamento para dentro do Snowflake em vez de tirar os dados de lá. O Snowpark Container Services, que roda aplicações em contêineres ao lado dos dados, está disponível para uso geral nas três nuvens, em regiões comerciais.

Para uma indústria, vale fazer um piloto de secure data sharing. Seja realista sobre o ponto de partida: a maior parte da troca de dados com fornecedores que vejo ainda é transferência de arquivos.

Compartilhar uma tabela governada é mais limpo, e você pode revogar o acesso. Comece com um fornecedor e um conjunto de dados, e prove o valor antes de planejar mais.

Snowflake costumava significar "seus dados no formato do Snowflake". Isso mudou, e os nomes também. Status atual, outubro de 2026:

Recurso	O que faz	Status (outubro de 2026)
Tabelas Apache Iceberg	Dados armazenados no formato aberto Iceberg, no seu armazenamento em nuvem ou no do Snowflake	GA desde junho de 2024; opção de armazenamento gerenciado pelo Snowflake em GA desde junho de 2026 (AWS e Azure comerciais)
Snowflake Horizon Catalog	Governança e catálogo construídos sobre o Apache Polaris; motores externos leem tabelas Iceberg gerenciadas pelo Snowflake via Iceberg REST API	Recomendado para novos clientes
Snowflake Open Catalog	Serviço gerenciado de Apache Polaris (antigo Polaris Catalog)	GA, mas fechado para novos clientes; quem já usa pode continuar
Hybrid tables (Unistore)	Tabelas baseadas em linhas para consultas transacionais de baixa latência ao lado das análises	GA apenas em regiões comerciais da AWS e do Azure
Snowflake Postgres	PostgreSQL totalmente gerenciado dentro da plataforma Snowflake	GA desde 24 de fevereiro de 2026, na AWS e no Azure

O resultado prático: as tabelas Iceberg permitem que Spark, Databricks ou outros motores trabalhem sobre os mesmos arquivos que o Snowflake consulta, o que reduz o aprisionamento ao fornecedor. A visão geral do Open Catalog do Snowflake agora orienta novos clientes a usar o Horizon Catalog.

Leia os limites das hybrid tables antes que alguém as apresente como um banco de dados operacional. Cada banco de dados tem um teto de 2 TB de dados em hybrid tables, e elas não suportam Fail-safe, compartilhamento de dados, replicação nem streams. Servem bem para uma tabela de consulta de uma aplicação.

Elas não são um banco de dados operacional. Se uma aplicação precisa de um ao lado das suas análises, o Snowflake Postgres chegou à disponibilidade geral em fevereiro de 2026 e é o encaixe mais honesto.

O Snowflake vende quatro edições: Standard, Enterprise, Business Critical e Virtual Private Snowflake (VPS). A edição decide quais recursos de segurança você recebe, e o preço do crédito sobe junto.

Recurso	Standard	Enterprise	Business Critical	VPS
Time Travel	1 dia	Até 90 dias	Até 90 dias	Até 90 dias
Warehouses multi-cluster	Não	Sim	Sim	Sim
Tri-Secret Secure (chave gerenciada pelo cliente)	Não	Não	Sim	Sim
Conectividade privada (AWS PrivateLink, Azure Private Link, Google Private Service Connect)	Não	Não	Sim	Sim
Suporte a HIPAA e PCI DSS	Não	Não	Sim	Sim
Ambiente dedicado, sem hardware compartilhado	Não	Não	Não	Sim

O Tri-Secret Secure combina uma chave do Snowflake com uma chave que você mantém no serviço de gerenciamento de chaves do seu provedor de nuvem. Revogue a sua chave e o Snowflake não consegue mais descriptografar seus dados. Para fornecedores de defesa e aeroespacial, esse controle importa mais do que qualquer recurso analítico.

Para trabalhos com o governo dos EUA, o Snowflake opera regiões SnowGov no AWS GovCloud e no Azure Government, abertas a clientes e contratados do governo americano. A página de regiões suportadas do Snowflake lista suporte a FedRAMP High, Impact Level 4 e ITAR nessas regiões, Impact Level 5 em uma região da AWS, e exige a edição Business Critical ou superior. Verifique a disponibilidade de recursos região por região: Open Catalog, hybrid tables e partes do Snowpark Container Services não estão disponíveis em todas as regiões de governo.

Nos programas de defesa em que trabalhei, a primeira pergunta nunca é "quão rápido ele é". É "onde os dados ficam, quem pode vê-los e conseguimos provar isso a um auditor". O Snowflake responde bem a isso na região e na edição certas.

Ele não consegue responder para dados que precisam ficar dentro do seu próprio prédio. Cargas de trabalho classificadas ou sob controle de exportação que exigem processamento on-premises precisam de outra plataforma, com o Snowflake cuidando do ambiente não classificado.

A maior parte do que vejo se encaixa em alguns padrões.

1. Relatórios corporativos e BI. Relatórios de finanças, vendas e operações a partir de dados do ERP (SAP, Oracle ou Microsoft Dynamics 365), com Power BI, Tableau ou similar por cima. Esse ainda é o uso central. Meu guia sobre como levar dados do ERP para o Snowflake cobre as opções de extração.
2. Dados de operações industriais. Os dados de fábrica e de operações que vi carregados no Snowflake são dados de planejamento da produção. Dados de historiadores, MES, qualidade e manutenção podem ficar ao lado deles, e dados semiestruturados de sensores em JSON são carregados de forma nativa.
3. Compartilhamento de dados com parceiros. Fornecedores, distribuidores e clientes podem consultar tabelas governadas diretamente. Na prática, a maior parte da troca com fornecedores que vejo ainda é transferência de arquivos.
4. Ciência de dados e IA sobre dados governados. Python via Snowpark e os serviços de IA do Snowflake, tratados no meu texto sobre Snowflake Cortex AI e Snowflake Intelligence.
5. Consolidação após aquisições. Vários ERPs, uma camada de relatórios, com cloning para ambientes de teste seguros.

Onde eu hesitaria:

1. Sistemas transacionais de alto volume. Hybrid tables e Snowflake Postgres ajudam, mas as transações do seu ERP e do seu MES pertencem aos seus próprios bancos de dados.
2. Controle de máquinas em tempo real. O Snowflake trabalha na escala de minutos, não de milissegundos. Receber dados de sensores em streaming tudo bem. Fechar um laço de controle, não.
3. Exigências rígidas de on-premises. Não existe instalação on-premises.
4. Machine learning personalizado e engenharia de dados pesados em Spark. Dá para fazer, mas muitas equipes acham o Databricks mais natural. Minha comparação Snowflake vs Databricks percorre essa escolha.

Snowflake schema vs star schema: outra coisa

Quem pesquisa sobre o Snowflake muitas vezes cai em "snowflake schema". Isso não tem nada a ver com o produto. Um snowflake schema é um padrão de modelagem de dados em que as tabelas de dimensão são normalizadas em subtabelas, de modo que o diagrama se ramifica como um floco de neve.

Um star schema mantém cada dimensão em uma única tabela plana. Você pode construir qualquer um dos dois modelos no Snowflake, ou em qualquer outro warehouse. A maioria das equipes de BI prefere star schemas, pelas consultas mais simples.

Antes de assinar, registre quatro decisões por escrito: qual edição você precisa para a sua posição de compliance, qual nuvem e região, como vai dividir as cargas de trabalho entre warehouses e se os seus dados ficam no formato do Snowflake ou em Iceberg. Peça ao fornecedor e ao seu integrador de sistemas que mostrem a estimativa de créditos por warehouse, não um único número anual. A maioria das surpresas de custo no Snowflake são decisões de arquitetura que ninguém deixou por escrito.

Se dados do ERP estiverem no escopo, leia antes por que a migração de dados SAP falha; os mesmos problemas de qualidade de dados acompanham você em qualquer plataforma. Se você quiser uma segunda opinião sobre uma decisão envolvendo o Snowflake, entre em contato.

Para que serve o Snowflake?

Principalmente como data warehouse em nuvem para relatórios e análises sobre dados de negócio, como dados de ERP, CRM e operações. As empresas também o usam para compartilhar dados vivos com parceiros, rodar ciência de dados em Python via Snowpark e construir aplicações de IA sobre dados governados.

Quais são as três camadas da arquitetura do Snowflake?

Armazenamento, computação e cloud services. O armazenamento guarda os dados em micro-partições colunares e comprimidas. A computação é formada por virtual warehouses que rodam as consultas. Os cloud services cuidam de segurança, metadados, otimização de consultas e transações. Armazenamento e computação escalam e são cobrados separadamente.

O Snowflake é um banco de dados ou um data warehouse?

Os dois, dependendo da definição. É um banco de dados SQL construído para cargas analíticas, e por isso costuma ser chamado de data warehouse em nuvem. Com tabelas Iceberg, hybrid tables e Snowflake Postgres, ele agora também cobre casos de uso de lakehouse e alguns casos transacionais, dentro de limites.

O Snowflake pode rodar on-premises?

Não. O Snowflake roda apenas na AWS, no Microsoft Azure e no Google Cloud. Para cargas de trabalho do governo dos EUA e de defesa, ele oferece regiões SnowGov no AWS GovCloud e no Azure Government, que exigem a edição Business Critical ou superior.

O snowflake schema tem relação com a empresa Snowflake?

Não. Um snowflake schema é um padrão de modelagem de dados com tabelas de dimensão normalizadas. Ele é anterior à empresa e funciona em qualquer warehouse.

De qual edição do Snowflake as empresas reguladas precisam?

Normalmente da Business Critical. Ela acrescenta Tri-Secret Secure com chave gerenciada pelo cliente, conectividade privada e suporte a HIPAA e PCI DSS, e é o mínimo exigido nas regiões de governo. O Virtual Private Snowflake acrescenta um ambiente dedicado, sem hardware compartilhado.