Alternatywa tylko UE dla MongoDB Atlas.

MongoDB Atlas to zarządzana oferta MongoDB od MongoDB Inc., notowanej na giełdzie amerykańskiej korporacji. Atlas działa na AWS, Azure lub GCP - co oznacza, że dane znajdują się u hyperscalera podlegającego jurysdykcji amerykańskiej, zarządzanego przez dostawcę bazy danych podlegającego jurysdykcji amerykańskiej. Dwie warstwy, obie amerykańskie. Dla suwerenności odpowiedzią jest albo samodzielnie zarządzany MongoDB na infrastrukturze unijnej (co obsługujemy dla klientów), albo migracja do innej bazy danych dokumentowej/obsługującej JSON podlegającej jurysdykcji UE (zazwyczaj PostgreSQL z JSONB, który pokrywa 90% przypadków użycia MongoDB).

Stany Zjednoczone Stack zastępczy, wyłącznie UE 10 zmapowanych usług
Umów rozmowę Najpierw zeskanuj swoją domenę
Dostawca
MongoDB Atlas
Siedziba
New York, NY
Jurysdykcja
Stany Zjednoczone
Reżim prawny
CLOUD Act, FISA 702

"Region UE" to nie suwerenność. Decydują cztery pytania.

Rezydencja danych mówi, gdzie leżą bity. Suwerenność mówi, który system prawny może wymusić dostęp. Odpowiedź musi się bronić we wszystkich czterech punktach, inaczej stack nie jest suwerenny.

Rezydencja

Gdzie dane są fizycznie przechowywane?

Nie "w chmurze": które centrum danych, w jakim kraju, pod jaką jurysdykcją.

Podprzetwarzający

Kto jeszcze znajduje się w Państwa ścieżce danych?

Każdy dostawca dotykający danych: CDN, przekaźnik e-mail, tracker błędów, pipeline analityczny.

Jurysdykcja

Czyje prawa mogą wymusić ujawnienie?

Dostawca z siedzibą w USA podlega FISA 702 i CLOUD Act, nawet gdy dane leżą we Frankfurcie.

Depozyt kluczy

Kto faktycznie ma klucze szyfrujące?

Jeśli dostawca chmury trzyma zarówno dane, jak i klucze, może je odczytać, niezależnie od jakiejkolwiek umowy powierzenia.

Nie spełnia AWS · Azure · GCP · Region UE

Nie spełnia kryterium jurysdykcji i depozytu kluczy.

Bity w UE, spółka matka w USA, podprzetwarzający z USA w domyślnej ścieżce, klucze zarządzane przez dostawcę.

Spełnia Stack zarządzany przez Binadit

Spełnia wszystkie cztery kryteria.

Hostowane w UE na infrastrukturze z siedzibą europejską. Zero podprzetwarzających z USA w domyślnej ścieżce. Klucze klienta lub europejskiego KMS. Wymienieni z nazwy w Państwa DPA z Artykułu 28.

Dlaczego zespoły wychodzą MongoDB Atlas

Migracje z MongoDB Atlas, które zakresowaliśmy, wynikają z dwóch powodów: obciążenia regulowane (opieka zdrowotna, fintech), gdzie podwójny skok AWS-przez-Atlas nie spełnia wymogów zgodności, oraz przeglądy kosztów, gdzie cennik Atlas per-klaster jest wyraźnie wysoki w porównaniu do rozwiązania samodzielnie zarządzanego. Cel migracji zależy od przypadku użycia. Dla obciążeń intensywnie wykorzystujących dokumenty ze złożoną agregacją, samodzielnie zarządzany MongoDB na infrastrukturze unijnej zachowuje powierzchnię API. Dla obciążeń wykorzystujących MongoDB jako magazyn JSON, migracja do PostgreSQL z JSONB jest często prostsza i tańsza w dłuższej perspektywie.

MongoDB Atlas usługi i ich odpowiedniki tylko z UE

Migracja to nie "zamiana jednej skrzynki na drugą". Poniższe mapowanie jest tym, co uruchamiamy dla klientów opuszczających MongoDB Atlas na gruncie Schrems II: pełna jurysdykcja UE, brak amerykańskiej spółki matki w ścieżce danych.

Atlas clusters (M10+)

Czego używamy zamiast tego
Binadit Managed Cloud Platform. MongoDB replica sets, lub PostgreSQL z JSONB tam, gdzie model dokumentowy jest cieńszy niż się wydaje.
Notatka inżynierska
Dla pełnej zgodności z MongoDB wzorcem produkcyjnym jest samodzielne zarządzanie na bare metal w UE. PostgreSQL JSONB to tańsza alternatywa, jeśli nie potrzebujesz funkcji specyficznych dla MongoDB.

Atlas Search (Lucene-based)

Czego używamy zamiast tego
Binadit Managed Cloud Platform. Elasticsearch lub OpenSearch, oraz MeiliSearch lub Typesense dla lżejszych obciążeń.
Notatka inżynierska
Atlas Search pod maską wykorzystuje Lucene; standardowy Elasticsearch / OpenSearch obsługuje równoważne obciążenia.

Atlas Vector Search

Czego używamy zamiast tego
Binadit Managed Cloud Platform. pgvector na PostgreSQL lub Qdrant dla większych zbiorów embeddingów.
Notatka inżynierska
Qdrant to najsilniejsza unijna suwerenna baza wektorowa - gotowa produkcyjnie i jednoznacznie podlegająca jurysdykcji UE.

App Services (Realm)

Czego używamy zamiast tego
Binadit Managed Cloud Platform. Obrazy Docker budowane w GitLab CI i wdrażane na Kubernetes, ze środowiskami review dla każdego brancha.
Notatka inżynierska
App Services i tak zostanie wycofane w latach 2025-2026; celem migracji jest własny backend na infrastrukturze UE.

Atlas Stream Processing

Czego używamy zamiast tego
Binadit Managed Cloud Platform. Apache Kafka lub Redpanda, kompatybilne z protokołem Kafka.
Notatka inżynierska
Dla obciążeń strumieniowych standardem branżowym jest Kafka + Flink.

Atlas Triggers

Czego używamy zamiast tego
Binadit Managed Cloud Platform. Triggery PostgreSQL i LISTEN/NOTIFY, lub Kubernetes CronJobs do zadań zaplanowanych.
Notatka inżynierska
Samodzielnie zarządzany MongoDB natywnie wspiera change streams; PostgreSQL ma swój własny mechanizm LISTEN/NOTIFY.

Atlas Online Archive

Czego używamy zamiast tego
Binadit Managed Cloud Platform. Warstwowe pule MinIO lub Ceph, z regułami lifecycle przenoszącymi dane cold na tańszy dysk.
Notatka inżynierska
Online Archive to w istocie zaplanowane warstwowanie danych; ten wzorzec można odtworzyć, wykorzystując unijny object storage jako warstwę zimną.

Charts (BI)

Czego używamy zamiast tego
Binadit Managed Cloud Platform. Apache Superset lub Metabase, połączone z Twoją hurtownią danych.
Notatka inżynierska
Metabase jest najbardziej zbliżony do Atlas Charts; działa wszędzie.

Data API / GraphQL

Czego używamy zamiast tego
Binadit Managed Cloud Platform. Traefik lub Kong, z rate limiting i OIDC na edge.
Notatka inżynierska
Dla backendów opartych na PostgreSQL, Hasura zapewnia natychmiastowe API GraphQL.

Atlas Backup (Continuous)

Czego używamy zamiast tego
Binadit Managed Cloud Platform. restic i pgBackRest dla danych, Velero dla stanu Kubernetes, do izolowanego storage w UE.
Notatka inżynierska
Dla samodzielnie zarządzanego MongoDB wzorcem produkcyjnym jest PITR oparte na oplogu; obsługujemy to dla klientów.

Jak migrujemy z MongoDB Atlas

Typowa migracja segmentu mid-market przebiega w trzech fazach. Poniższe liczby zakładają zespół inżynierski 6-10 osób i umiarkowanie złożony stack aplikacyjny.

  1. Dni 1-5

    Decyzja dotycząca przypadku użycia: Mongo czy Postgres

    Przeanalizuj wzorce zapytań. Jeśli korzystasz z funkcji specyficznych dla Mongo (aggregation pipelines, change streams, złożone zapytania Atlas Search) → self-managed MongoDB w UE. Jeśli traktujesz Mongo jako magazyn JSON → migracja do PostgreSQL JSONB. Wynik: decyzja o docelowej architekturze.

  2. Dni 5-14

    Provisioning klastra + replikacja

    Udostępniony samodzielnie zarządzany klaster MongoDB (zestaw replik z 3 węzłami, bare metal w UE). Wstępna synchronizacja za pomocą narzędzia Atlas Live Migration. Skonfigurowano monitoring i backup.

  3. Tygodnie 2-4

    Migracja aplikacji

    Connection string zmieniony. Okres walidacji tylko do odczytu. Przełączenie w oknie niskiego ruchu. Klaster Atlas wycofany po weryfikacji.

5-letnie TCO przy migracji z Atlas → samodzielnie zarządzany MongoDB na bare metal w UE: zazwyczaj 70-85% taniej w skali produkcyjnej. Typowy klaster M30 Atlas (2000$+/miesiąc) zastępowany jest 3-węzłowym dedykowanym klastrem MongoDB, którym zarządzamy, z porównywalną lub lepszą wydajnością. Kompromisem jest odpowiedzialność operacyjna, którą przejmujemy jako partner zarządzający.

Często zadawane pytania

Zobacz wszystkie często zadawane pytania

Atlas ma regiony UE na AWS Frankfurt - czy to rozwiązuje kwestię suwerenności?
Nie. Dwie warstwy amerykańskiej jurysdykcji: MongoDB Inc. (siedziba w USA) i AWS (siedziba w USA). CLOUD Act dotyczy obu. Dla obciążeń wymagających ścisłej zgodności z Schrems II, obie muszą zostać wyeliminowane.
Czy powinniśmy przejść na PostgreSQL czy samodzielnie zarządzany MongoDB?
Zależy od użycia. Jeśli korzystasz z funkcji specyficznych dla MongoDB (złożone agregacje, $lookup, change streams między kolekcjami, Atlas Search), samodzielnie zarządzany MongoDB na bare metal w UE zachowuje API. Jeśli MongoDB służy głównie do przechowywania dokumentów JSON z prostymi zapytaniami, PostgreSQL JSONB jest tańszy, bardziej wydajny w zapytaniach analitycznych i prostszy w obsłudze.
Jak operacyjnie wymagający jest self-managed MongoDB?
Dla 3-węzłowego replica set z backupami i monitoringiem wymagana jest rzeczywista praca operacyjna - zazwyczaj 2-4 godziny tygodniowo poświęcone na obsługę oraz reagowanie na incydenty. Zapewniamy to klientom w ramach relacji zarządzanej infrastruktury; to znany wzorzec.
A co z własną, self-hostowaną wersją enterprise MongoDB?
MongoDB Enterprise Advanced działa na Twojej infrastrukturze, ale licencja pochodzi od MongoDB Inc. - strony umowy podlegającej jurysdykcji amerykańskiej. Dla czystej suwerenności opcją jest MongoDB Community Edition (open-source, AGPL). Dla większości obciążeń produkcyjnych wersja Community jest wystarczająca.
Atlas Vector Search jest kluczowy dla naszych funkcji AI. Jaki jest odpowiednik w UE?
Qdrant (z siedzibą w Niemczech) to najsilniejsza suwerenna baza wektorowa. Qdrant Cloud ma regiony w UE; Qdrant self-hosted to ten sam silnik. Migracja z Atlas Vector Search do Qdrant jest prosta (wektory to wektory), a jedynym istotnym zadaniem jest mapowanie schematu.
Ile trwa wyjście z Atlas?
Dla pojedynczego obciążenia typu replica-set z umiarkowaną ilością danych (50-200GB): 2-4 tygodnie. Dla klastrów shardowanych lub bardzo dużych zbiorów danych: 6-12 tygodni. Harmonogram jest zdominowany przez fazę migracji na żywo, a nie zmiany po stronie aplikacji.

Zaplanuj wyjście z MongoDB Atlas.

30-minutowa rozmowa zakresowa. Mapujemy Państwa stack względem alternatyw tylko z UE, szacujemy nakład pracy migracji i mówimy, czy to właściwa decyzja.

Umów rozmowę Porównaj innego dostawcę