Alternativa apenas UE a Snowflake.

Snowflake é o data warehouse na cloud que conquistou o mercado de analytics através da separação entre compute e storage, com regiões UE na AWS, Azure ou GCP. A Snowflake Inc. é uma corporação do Delaware; as regiões UE residem em infraestrutura de hyperscalers dos EUA - ou seja, duas camadas de jurisdição dos EUA. Para workloads de analytics sobre dados de clientes UE, a conformidade com Schrems II é genuinamente difícil no Snowflake. As alternativas soberanas são: ClickHouse (data warehouse colunar open-source), DuckDB (analytics embutido), ou PostgreSQL com extensões colunares apropriadas - todas passíveis de deployment em infraestrutura soberana UE.

Estados Unidos Stack de substituição, apenas UE 10 serviços mapeados

Agendar uma chamada Verifique primeiro o seu domínio

Fornecedor: Snowflake
Sede: Bozeman, MT
Jurisdição: Estados Unidos
Regime jurídico: CLOUD Act, FISA 702

"Região UE" não é soberania. Quatro perguntas decidem.

A residência de dados diz onde estão os bits. A soberania diz que sistema legal pode obrigar ao acesso. A resposta tem de se sustentar nos quatro pontos, caso contrário a stack não é soberana.

Residência

Onde os dados estão fisicamente armazenados?

Não "na cloud": que centro de dados, em que país, sob que jurisdição.

Subprocessadores

Quem mais está no seu caminho de dados?

Cada fornecedor que toca os dados: o CDN, o relay de e-mail, o rastreador de erros, o pipeline de analytics.

Jurisdição

Quais leis podem forçar a divulgação?

Um fornecedor com sede nos EUA está sujeito à FISA 702 e à CLOUD Act, mesmo com os dados em Frankfurt.

Custódia de chaves

Quem detém realmente as chaves de cifragem?

Se o fornecedor cloud detém tanto os dados como as chaves, consegue lê-los, independentemente de qualquer DPA.

Não cumpre AWS · Azure · GCP · Região da UE

Falha em jurisdição e custódia de chaves.

Bits na UE, casa-mãe nos EUA, subprocessadores americanos no caminho predefinido, chaves geridas pelo fornecedor.

Cumpre Stack gerida pela Binadit

Passa nos quatro.

Hospedado na UE em infraestrutura com sede europeia. Zero subprocessadores americanos no caminho padrão. Chaves do cliente ou de KMS europeu. Nomeados no seu DPA Artigo 28.

Porque é que as equipas estão a sair Snowflake

As saídas do Snowflake que já orçamentámos vêm de workloads regulados, onde o data warehouse de analytics contém dados pessoais de clientes da UE, e a análise do Schrems II falha em múltiplas camadas. O desafio único da migração: data warehouses são grandes, as queries são complexas, e os pipelines de dbt / Looker / Tableau precisam de ser reapontados. A resposta honesta para uma saída do Snowflake é 3-6 meses de trabalho cuidadoso, não uma troca rápida. Onde estão as poupanças: os créditos do Snowflake a grande escala ($20k-100k+/mês é comum) reduzem-se a uma fração com ClickHouse em bare metal na UE.

Snowflake serviços e os seus equivalentes apenas na UE

Uma migração não é "trocar uma caixa por outra". O mapeamento abaixo é o que executamos para clientes que saem de Snowflake com base em Schrems II: jurisdição da UE completa, sem empresa-mãe norte-americana no caminho dos dados.

Snowflake serviço	O que usamos no lugar	Nota de engenharia
Snowflake compute (warehouses)	Binadit Managed Cloud Platform. ClickHouse ou PostgreSQL com extensões columnar, modelado com dbt.	O ClickHouse é a alternativa soberana mais forte para workloads OLAP. Para workloads de queries ad-hoc, o Trino sobre object storage na UE é o padrão lakehouse.
Snowflake storage	Binadit Managed Cloud Platform. Pools em camadas MinIO ou Ceph, com regras de lifecycle a mover dados frios para disco mais económico.	Para arquitetura lakehouse, storage compatível com S3 da UE como camada de dados, com ClickHouse ou Trino como engine de queries.
Snowpipe (continuous ingestion)	Binadit Managed Cloud Platform. Kafka ou Redpanda para ClickHouse, orquestrado com dbt.	Para ingestão baseada em Kafka, o ClickHouse tem um engine Kafka nativo. Para ingestão em batch, Airflow em compute da UE.
Streams & Tasks	Binadit Managed Cloud Platform. Triggers PostgreSQL e LISTEN/NOTIFY, ou Kubernetes CronJobs para trabalho agendado.	As materialized views no ClickHouse cobrem a maioria dos casos de uso de "Stream".
Snowpark (Python/Scala in DB)	Binadit Managed Cloud Platform. PostgreSQL com PL/Python, ou workers junto à base de dados em Python.	Para ML e feature engineering na camada de warehouse, PySpark em compute da UE é o padrão standard.
Time Travel + Zero-Copy Cloning	Binadit Managed Cloud Platform. Recuperação point-in-time com pgBackRest, com snapshots ZFS ou Ceph para clones instantâneos.	O Time Travel do Snowflake é uma funcionalidade única; os snapshots do ClickHouse oferecem um equivalente mais rudimentar.
Secure Data Sharing	Binadit Managed Cloud Platform. Réplicas read-only, exports assinados, ou uma API delimitada à frente do dataset.	O Secure Data Sharing não tem um equivalente direto; a migração implica redesenhar o padrão de partilha de dados.
Snowflake Marketplace	Binadit DevOps & Support. Os componentes que efetivamente utiliza, implementados e operados como parte da sua stack.	Para datasets aos quais atualmente subscreve via Marketplace, normalmente são necessários contratos diretos com o fornecedor.
Snowflake Cortex (LLMs)	Binadit Private Infrastructure. Modelos open-weight self-hosted em hardware GPU dedicado, servidos através de vLLM ou Ollama.	O Cortex é recente; o espaço soberano de LLMs da UE (Mistral, Aleph Alpha) amadureceu até se tornar uma alternativa real.
BI tool integrations (Tableau, Looker, dbt Cloud)	Binadit Managed Cloud Platform. Apache Superset ou Metabase, ligado ao seu warehouse.	A camada de ferramentas de BI transfere-se normalmente sem problemas com novas connection strings; dbt Cloud → dbt Core em CI self-hosted europeu.

Snowflake compute (warehouses)

O que usamos no lugar: Binadit Managed Cloud Platform. ClickHouse ou PostgreSQL com extensões columnar, modelado com dbt.
Nota de engenharia: O ClickHouse é a alternativa soberana mais forte para workloads OLAP. Para workloads de queries ad-hoc, o Trino sobre object storage na UE é o padrão lakehouse.

Snowflake storage

O que usamos no lugar: Binadit Managed Cloud Platform. Pools em camadas MinIO ou Ceph, com regras de lifecycle a mover dados frios para disco mais económico.
Nota de engenharia: Para arquitetura lakehouse, storage compatível com S3 da UE como camada de dados, com ClickHouse ou Trino como engine de queries.

Snowpipe (continuous ingestion)

O que usamos no lugar: Binadit Managed Cloud Platform. Kafka ou Redpanda para ClickHouse, orquestrado com dbt.
Nota de engenharia: Para ingestão baseada em Kafka, o ClickHouse tem um engine Kafka nativo. Para ingestão em batch, Airflow em compute da UE.

Streams & Tasks

O que usamos no lugar: Binadit Managed Cloud Platform. Triggers PostgreSQL e LISTEN/NOTIFY, ou Kubernetes CronJobs para trabalho agendado.
Nota de engenharia: As materialized views no ClickHouse cobrem a maioria dos casos de uso de "Stream".

Snowpark (Python/Scala in DB)

O que usamos no lugar: Binadit Managed Cloud Platform. PostgreSQL com PL/Python, ou workers junto à base de dados em Python.
Nota de engenharia: Para ML e feature engineering na camada de warehouse, PySpark em compute da UE é o padrão standard.

Time Travel + Zero-Copy Cloning

O que usamos no lugar: Binadit Managed Cloud Platform. Recuperação point-in-time com pgBackRest, com snapshots ZFS ou Ceph para clones instantâneos.
Nota de engenharia: O Time Travel do Snowflake é uma funcionalidade única; os snapshots do ClickHouse oferecem um equivalente mais rudimentar.

Secure Data Sharing

O que usamos no lugar: Binadit Managed Cloud Platform. Réplicas read-only, exports assinados, ou uma API delimitada à frente do dataset.
Nota de engenharia: O Secure Data Sharing não tem um equivalente direto; a migração implica redesenhar o padrão de partilha de dados.

Snowflake Marketplace

O que usamos no lugar: Binadit DevOps & Support. Os componentes que efetivamente utiliza, implementados e operados como parte da sua stack.
Nota de engenharia: Para datasets aos quais atualmente subscreve via Marketplace, normalmente são necessários contratos diretos com o fornecedor.

Snowflake Cortex (LLMs)

O que usamos no lugar: Binadit Private Infrastructure. Modelos open-weight self-hosted em hardware GPU dedicado, servidos através de vLLM ou Ollama.
Nota de engenharia: O Cortex é recente; o espaço soberano de LLMs da UE (Mistral, Aleph Alpha) amadureceu até se tornar uma alternativa real.

BI tool integrations (Tableau, Looker, dbt Cloud)

O que usamos no lugar: Binadit Managed Cloud Platform. Apache Superset ou Metabase, ligado ao seu warehouse.
Nota de engenharia: A camada de ferramentas de BI transfere-se normalmente sem problemas com novas connection strings; dbt Cloud → dbt Core em CI self-hosted europeu.

Como migramos de Snowflake

Uma migração típica de mid-market decorre em três fases. Os números abaixo assumem uma equipa de engenharia de 6 a 10 pessoas e uma stack de aplicação moderadamente complexa.

Semanas 1-3

Decisão de arquitetura + auditoria

Decidir entre ClickHouse vs Trino+lakehouse vs PostgreSQL com base nos padrões de queries e volume de dados. Inventariar cada modelo dbt, cada dashboard, cada integração externa. A decisão de arquitetura domina o cronograma.
Semanas 3-10

Piloto + execução paralela

Migramos um subconjunto representativo de workloads para o target na UE. Executamos em paralelo para validação. Ajustamos o dimensionamento do cluster ClickHouse com base em padrões reais de queries. Os modelos dbt são convertidos (a maioria executa sem alterações no dbt Core com troca de adapter).
Semanas 10-24

Transição completa

Migração faseada das restantes cargas de trabalho. Ferramentas de BI redirecionadas. Contas Snowflake reduzidas de âmbito. Corte final com plano de rollback; Snowflake mantido para acesso de arquivo durante 60-90 dias após o corte.

TCO a 5 anos em migrações Snowflake → ClickHouse: normalmente 60-85% mais barato à escala. Uma equipa que gasta $50k/mês em créditos Snowflake substitui-os muitas vezes por €5-10k/mês de infraestrutura ClickHouse na UE, mais a taxa de parceiro managed. O ponto de equilíbrio situa-se em torno dos $5-10k/mês de gasto em Snowflake; abaixo disso, o custo de engenharia da migração pode exceder a poupança obtida num horizonte de 3 anos.

Perguntas frequentes

Ver todas as perguntas frequentes

O Snowflake tem Frankfurt e outras regiões na UE - isso resolve o RGPD?

Não. A Snowflake Inc. tem sede nos EUA (jurisdição da empresa-mãe), e as regiões UE funcionam sobre AWS/Azure/GCP - também sediadas nos EUA (jurisdição da infraestrutura). Duas camadas de exposição legal aos EUA ao abrigo do CLOUD Act e da FISA 702. Para workloads que exigem rigor Schrems II, nenhuma das opções é aceitável.

O ClickHouse é realmente comparável ao Snowflake?

Para workloads de queries OLAP, o ClickHouse é genuinamente competitivo - frequentemente mais rápido em hardware equivalente. As diferenças: o ClickHouse requer mais expertise operacional, a separação entre compute e storage do Snowflake é mais difícil de replicar de forma limpa, e o ecossistema do Snowflake (Marketplace, Cortex, etc.) não existe totalmente no ClickHouse. Para workloads puramente analíticos, a diferença é pequena.

E quanto às ofertas de ClickHouse gerido com região na UE?

Verifique realmente sobre o que a região da UE está a correr. Várias plataformas de analytics geridas anunciam uma região UE que está, ela própria, alojada num hyperscaler dos EUA, o que deixa exatamente o problema de dupla jurisdição que estava a tentar resolver, uma camada mais abaixo. Nós corremos o ClickHouse em infraestrutura onde essa questão tem uma resposta única.

Como é que o dbt se encaixa?

O dbt Core é open-source e funciona em qualquer lugar; o dbt Cloud é da dbt Labs Inc. (EUA). Para cargas de trabalho soberanas, o dbt Core num runner de CI autoalojado (GitLab CI UE, Forgejo Actions) substitui o dbt Cloud. Os modelos dbt reais são portados sem problemas com a troca do adaptador de warehouse (snowflake → clickhouse).

Quanto tempo demora realmente uma saída do Snowflake?

Para uma utilização Snowflake pequena a média ($5-20k/mês, dezenas de modelos dbt): 3-6 meses de tempo decorrido. Para Snowflake empresarial ($50k+/mês, centenas de modelos, partilha de dados complexa): 9-18 meses. As migrações Snowflake não são projetos de fim de semana - exigem planeamento, execuções paralelas e uma coreografia cuidadosa da camada de BI.

Podemos manter parte do Snowflake e migrar o resto?

O modelo híbrido é por vezes a resposta certa para funcionalidades muito específicas exclusivas do Snowflake. A disciplina: manter no Snowflake apenas workloads sem dados pessoais (ex.: analytics interno sobre métricas agregadas sem PII), e documentar a fronteira no DPA. Para a maioria dos workloads regulados, a saída total é mais limpa do que o esforço de documentação de um modelo híbrido.

Planeie a sua saída de Snowflake.

Chamada de scoping de 30 minutos. Mapeamos a sua stack contra alternativas apenas UE, estimamos o esforço de migração e dizemos-lhe se é a decisão certa.

Agendar uma chamada Comparar outro fornecedor