Alternativa apenas UE a MongoDB Atlas.

O MongoDB Atlas é a oferta gerida de MongoDB da MongoDB Inc., uma corporação dos EUA cotada em bolsa. O Atlas corre em AWS, Azure ou GCP - o que significa que os dados residem num hyperscaler de jurisdição dos EUA, gerido por um fornecedor de base de dados de jurisdição dos EUA. Duas camadas, ambas dos EUA. Para soberania, a resposta é ou MongoDB self-managed em infraestrutura da UE (que operamos para clientes) ou migração para uma base de dados diferente com capacidade documento/JSON sob jurisdição da UE (tipicamente PostgreSQL com JSONB, que cobre 90% dos casos de uso do MongoDB).

Estados Unidos Stack de substituição, apenas UE 10 serviços mapeados
Agendar uma chamada Verifique primeiro o seu domínio
Fornecedor
MongoDB Atlas
Sede
New York, NY
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 MongoDB Atlas

As saídas de MongoDB Atlas que escopámos surgem de dois ângulos: workloads regulados (saúde, fintech) onde o duplo salto AWS-via-Atlas falha na conformidade, e revisões de custos onde o pricing per-cluster do Atlas é genuinamente elevado face a self-managed. O target de migração depende do caso de uso. Para workloads intensivos em documentos com agregação complexa, o MongoDB self-managed em compute na UE preserva a superfície da API. Para workloads que usam o MongoDB como armazenamento JSON, migrar para PostgreSQL com JSONB é frequentemente mais simples e mais económico a longo prazo.

MongoDB Atlas 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 MongoDB Atlas com base em Schrems II: jurisdição da UE completa, sem empresa-mãe norte-americana no caminho dos dados.

Atlas clusters (M10+)

O que usamos no lugar
Binadit Managed Cloud Platform. Replica sets MongoDB, ou PostgreSQL com JSONB onde o modelo de documentos é mais simples do que parece.
Nota de engenharia
Para compatibilidade pura com MongoDB, self-managed em bare metal na UE é o padrão de produção. PostgreSQL JSONB é a alternativa mais económica se não precisar de funcionalidades específicas do MongoDB.

Atlas Search (Lucene-based)

O que usamos no lugar
Binadit Managed Cloud Platform. Elasticsearch ou OpenSearch, e MeiliSearch ou Typesense para workloads mais leves.
Nota de engenharia
O Atlas Search é Lucene por baixo; Elasticsearch / OpenSearch padrão lida com workloads equivalentes.

Atlas Vector Search

O que usamos no lugar
Binadit Managed Cloud Platform. pgvector no PostgreSQL, ou Qdrant para conjuntos de embeddings maiores.
Nota de engenharia
O Qdrant é a base de dados vetorial soberana europeia mais robusta - pronta para produção e explicitamente sob jurisdição da UE.

App Services (Realm)

O que usamos no lugar
Binadit Managed Cloud Platform. Imagens Docker construídas no GitLab CI e implantadas no Kubernetes, com review environments por branch.
Nota de engenharia
O App Services está a ser descontinuado em 2025-2026 de qualquer forma; o alvo de migração é um backend personalizado em infraestrutura europeia.

Atlas Stream Processing

O que usamos no lugar
Binadit Managed Cloud Platform. Apache Kafka ou Redpanda, compatível com o protocolo Kafka.
Nota de engenharia
Para workloads de streaming, Kafka + Flink é o padrão da indústria.

Atlas Triggers

O que usamos no lugar
Binadit Managed Cloud Platform. Triggers PostgreSQL e LISTEN/NOTIFY, ou Kubernetes CronJobs para trabalho agendado.
Nota de engenharia
O MongoDB autogerido suporta change streams de forma nativa; o PostgreSQL tem o seu próprio mecanismo LISTEN/NOTIFY.

Atlas Online Archive

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
O Online Archive é essencialmente tiering agendado; replique o padrão com object storage europeu como tier frio.

Charts (BI)

O que usamos no lugar
Binadit Managed Cloud Platform. Apache Superset ou Metabase, ligado ao seu warehouse.
Nota de engenharia
O Metabase é o mais parecido com o Atlas Charts; corre em qualquer lugar.

Data API / GraphQL

O que usamos no lugar
Binadit Managed Cloud Platform. Traefik ou Kong, com rate limiting e OIDC na edge.
Nota de engenharia
Para backends PostgreSQL, o Hasura fornece APIs GraphQL instantâneas.

Atlas Backup (Continuous)

O que usamos no lugar
Binadit Managed Cloud Platform. restic e pgBackRest para dados, Velero para o estado do Kubernetes, para storage isolado na UE.
Nota de engenharia
Para MongoDB self-managed, PITR baseado em oplog é o padrão de produção; operamos isto para clientes.

Como migramos de MongoDB Atlas

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.

  1. Dias 1-5

    Decisão por caso de uso: Mongo ou Postgres

    Audite os padrões de queries. Se usa funcionalidades específicas do Mongo (aggregation pipelines, change streams, queries complexas do Atlas Search) → MongoDB self-managed na UE. Se trata o Mongo como um JSON store → migre para PostgreSQL JSONB. Resultado: decisão de arquitetura de destino.

  2. Dias 5-14

    Provisionamento de cluster + replicação

    Cluster MongoDB autogerido (replica set de 3 nós, bare metal na UE) provisionado. Sincronização inicial via ferramenta Atlas Live Migration. Monitorização e backup configurados.

  3. Semanas 2-4

    Cutover da aplicação

    Connection string alterada. Período de validação read-only. Cutover durante janela de baixo tráfego. Cluster Atlas desativado após verificação.

TCO a 5 anos em migrações Atlas → MongoDB self-managed em bare metal na UE: normalmente 70-85% mais barato à escala de produção. Um cluster Atlas M30 típico ($2k+/mês) é substituído por um cluster MongoDB dedicado de 3 nós que operamos, com desempenho comparável ou superior. O trade-off é a responsabilidade operacional, que assumimos como parceiro managed.

Perguntas frequentes

Ver todas as perguntas frequentes

O Atlas tem regiões na UE na AWS Frankfurt - isso resolve a questão da soberania?
Não. Duas camadas de jurisdição dos EUA: a MongoDB Inc. (sediada nos EUA) e a AWS (sediada nos EUA). O CLOUD Act aplica-se a ambas. Para workloads que exigem rigor Schrems II, ambas têm de ser eliminadas.
Devemos migrar para PostgreSQL ou para MongoDB autogerido?
Depende da utilização. Se usar funcionalidades específicas do MongoDB (aggregation pipelines complexos, $lookup, change streams entre collections, Atlas Search), o MongoDB self-managed em bare metal na UE preserva a API. Se o MongoDB estiver a ser usado principalmente para armazenar documentos JSON com queries simples, o PostgreSQL JSONB é mais económico, mais capaz para queries analíticas e mais simples de operar.
Quão operacional é o MongoDB autogerido?
Para um replica set de 3 nós com backups e monitorização, requer trabalho operacional real - normalmente 2-4 horas por semana de atenção mais resposta a incidentes. Operamos isto para clientes como parte da relação de infraestrutura managed; é um padrão conhecido.
E quanto à própria versão enterprise self-hosted do MongoDB?
O MongoDB Enterprise Advanced corre na sua infraestrutura, mas a licença é da MongoDB Inc. - uma parte contratante dos EUA. Para soberania pura, o MongoDB Community Edition (open-source, AGPL) é a opção. Para a maioria dos workloads de produção, o Community é suficiente.
O Atlas Vector Search é crítico para as nossas funcionalidades de AI. Qual é o equivalente na UE?
O Qdrant (sediado na Alemanha) é a base de dados vetorial soberana mais forte. O Qdrant Cloud tem regiões na UE; o Qdrant self-hosted é o mesmo motor. A migração do Atlas Vector Search para o Qdrant é direta (vetores são vetores), sendo o mapeamento de esquema o único trabalho relevante.
Quanto tempo demora uma saída do Atlas?
Para uma carga de trabalho com um único replica-set e dados moderados (50-200GB): 2-4 semanas. Para clusters com sharding ou dados muito grandes: 6-12 semanas. O cronograma é dominado pela fase de live-migration, não pelas alterações do lado da aplicação.

Planeie a sua saída de MongoDB Atlas.

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