Alternatywa tylko UE dla Supabase.

Supabase to open-source'owa alternatywa dla Firebase: hostowany Postgres + Auth + Storage + Edge Functions + Realtime z dopracowanym doświadczeniem deweloperskim. Supabase Inc. to amerykańska spółka prawa stanu Delaware; regiony UE (Frankfurt, Irlandia, Londyn, Paryż) działają na infrastrukturze AWS pod podwójną kontrolą jurysdykcyjną - Supabase i AWS, obie amerykańskie. Dobra wiadomość: Supabase jest open-source. Możesz samodzielnie hostować cały stos na infrastrukturze UE z pełną parytetowością funkcji - to suwerenna alternatywa, którą wdrażamy dla klientów.

Stany Zjednoczone Stack zastępczy, wyłącznie UE 10 zmapowanych usług

Umów rozmowę Najpierw zeskanuj swoją domenę

Dostawca: Supabase
Siedziba: San Francisco, CA
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ą Supabase

Migracje z Supabase, które przeprowadzaliśmy, mają jeden wspólny wyzwalacz: firma B2B SaaS wybrała Supabase ze względu na doświadczenie deweloperskie, rozrosła się do klientów enterprise i odkryła, że "Supabase Frankfurt na AWS Ireland" to dwie warstwy procesorów podlegających amerykańskiej jurysdykcji, które nie przechodzą analizy Schrems II. Sam zespół Supabase publicznie omawiał ograniczenia suwerenności danych na swoim blogu. Samodzielne hostowanie Supabase na infrastrukturze UE zachowuje pełne doświadczenie deweloperskie (ten sam klient supabase-js działa bez zmian), jednocześnie przenosząc wszystko pod pełną jurysdykcję UE.

Supabase 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 Supabase na gruncie Schrems II: pełna jurysdykcja UE, brak amerykańskiej spółki matki w ścieżce danych.

Supabase usługa	Czego używamy zamiast tego	Notatka inżynierska
Postgres (managed)	Binadit Managed Cloud Platform. PostgreSQL lub MySQL z Patroni do failover i pgBackRest do point-in-time recovery.	Replikacja strumieniowa pozwala na przełączenie z przestojem liczonym w sekundach zamiast okna serwisowego, a przywracanie danych jest regularnie testowane, a nie zakładane.
Auth (GoTrue)	Binadit Managed Cloud Platform. Keycloak lub Authentik jako dostawca identity, z OIDC i SAML.	GoTrue jest częścią otwartego stosu Supabase; samodzielny hosting zachowuje uwierzytelnianie oparte na JWT z logowaniem społecznościowym, magic links i MFA.
Storage (S3-compatible)	Binadit Managed Cloud Platform. MinIO lub Ceph RGW, kompatybilne z S3.	Supabase Storage to warstwa usługowa nad pamięcią zgodną z S3; działa z dowolnym backendem S3 w UE.
Edge Functions (Deno)	Binadit Managed Cloud Platform. Knative lub OpenFaaS na Twoim klastrze Kubernetes.	Edge Functions działają w środowisku uruchomieniowym Deno; odpowiednik self-hosted uruchomisz na dowolnej platformie kontenerowej w UE.
Realtime (Postgres CDC)	Binadit Managed Cloud Platform. Replikacja logiczna PostgreSQL do warstwy websocket, lub NATS do fan-out.	Realtime jest open-source; self-hosting zachowuje pub/sub oparty na WebSocket.
Vector embeddings (pgvector)	Binadit Managed Cloud Platform. pgvector na PostgreSQL lub Qdrant dla większych zbiorów embeddingów.	Dla dedykowanych obciążeń wektorowych, Qdrant Cloud EU jest alternatywą suwerenną z założenia.
Studio (admin UI)	Binadit DevOps & Support. pgAdmin lub Metabase do dostępu do danych, z Grafaną do widoków operacyjnych.	Studio jest częścią dystrybucji self-hosted.
Database backups	Binadit Managed Cloud Platform. restic i pgBackRest dla danych, Velero dla stanu Kubernetes, do izolowanego storage w UE.	WAL-G z backendem object storage w UE to wzorzec produkcyjny.
API (PostgREST)	Binadit Managed Cloud Platform. Traefik lub Kong, z rate limiting i OIDC na edge.	PostgREST jest open-source; self-hosting zachowuje generowanie API REST.
CLI / Migrations	Binadit DevOps & Support. kubectl, Terraform i GitLab CI, z wrapperami dostosowanymi do projektu tam, gdzie to pomaga.	Supabase CLI obsługuje `--db-url`, aby wskazać instancje self-hosted.

Postgres (managed)

Czego używamy zamiast tego: Binadit Managed Cloud Platform. PostgreSQL lub MySQL z Patroni do failover i pgBackRest do point-in-time recovery.
Notatka inżynierska: Replikacja strumieniowa pozwala na przełączenie z przestojem liczonym w sekundach zamiast okna serwisowego, a przywracanie danych jest regularnie testowane, a nie zakładane.

Auth (GoTrue)

Czego używamy zamiast tego: Binadit Managed Cloud Platform. Keycloak lub Authentik jako dostawca identity, z OIDC i SAML.
Notatka inżynierska: GoTrue jest częścią otwartego stosu Supabase; samodzielny hosting zachowuje uwierzytelnianie oparte na JWT z logowaniem społecznościowym, magic links i MFA.

Storage (S3-compatible)

Czego używamy zamiast tego: Binadit Managed Cloud Platform. MinIO lub Ceph RGW, kompatybilne z S3.
Notatka inżynierska: Supabase Storage to warstwa usługowa nad pamięcią zgodną z S3; działa z dowolnym backendem S3 w UE.

Edge Functions (Deno)

Czego używamy zamiast tego: Binadit Managed Cloud Platform. Knative lub OpenFaaS na Twoim klastrze Kubernetes.
Notatka inżynierska: Edge Functions działają w środowisku uruchomieniowym Deno; odpowiednik self-hosted uruchomisz na dowolnej platformie kontenerowej w UE.

Realtime (Postgres CDC)

Czego używamy zamiast tego: Binadit Managed Cloud Platform. Replikacja logiczna PostgreSQL do warstwy websocket, lub NATS do fan-out.
Notatka inżynierska: Realtime jest open-source; self-hosting zachowuje pub/sub oparty na WebSocket.

Vector embeddings (pgvector)

Czego używamy zamiast tego: Binadit Managed Cloud Platform. pgvector na PostgreSQL lub Qdrant dla większych zbiorów embeddingów.
Notatka inżynierska: Dla dedykowanych obciążeń wektorowych, Qdrant Cloud EU jest alternatywą suwerenną z założenia.

Studio (admin UI)

Czego używamy zamiast tego: Binadit DevOps & Support. pgAdmin lub Metabase do dostępu do danych, z Grafaną do widoków operacyjnych.
Notatka inżynierska: Studio jest częścią dystrybucji self-hosted.

Database backups

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: WAL-G z backendem object storage w UE to wzorzec produkcyjny.

API (PostgREST)

Czego używamy zamiast tego: Binadit Managed Cloud Platform. Traefik lub Kong, z rate limiting i OIDC na edge.
Notatka inżynierska: PostgREST jest open-source; self-hosting zachowuje generowanie API REST.

CLI / Migrations

Czego używamy zamiast tego: Binadit DevOps & Support. kubectl, Terraform i GitLab CI, z wrapperami dostosowanymi do projektu tam, gdzie to pomaga.
Notatka inżynierska: Supabase CLI obsługuje `--db-url`, aby wskazać instancje self-hosted.

Jak migrujemy z Supabase

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.

Dni 1-5

Wdrożenie Supabase we własnej infrastrukturze

Wdrożenie self-hosted stosu Supabase na Binadit (Docker Compose lub Kubernetes). Konfiguracja dostawców uwierzytelniania, backendu storage, środowiska Edge Functions. Konfiguracja monitoringu i backupów.
Dni 6-14

Baza danych + migracja uwierzytelniania

Zrzut i przywrócenie Postgres do instancji self-hosted. Konta użytkowników migrowane przez eksport danych z dostawcy uwierzytelniania. Kubełki storage lustrzane. Edge Functions wdrożone ponownie.
Tygodnie 2-3

Migracja aplikacji

Konfiguracja aplikacji zaktualizowana, aby wskazywała na self-hosted URL Supabase. Ten sam klient supabase-js, te same zasady RLS, te same przepływy uwierzytelniania. Migracja z oknem weryfikacyjnym.

Samodzielnie hostowane Supabase na pojedynczej małej maszynie wirtualnej zastępuje Supabase Pro za 25 USD za projekt miesięcznie plus zużycie na projekt. Dla obciążeń wieloprojektowych, oszczędności się kumulują: typowy plan zespołowy Supabase (599 USD/miesiąc) staje się 40-100 €/miesiąc w surowej infrastrukturze plus opłata za partnera zarządzającego, jeśli nie chcesz obsługiwać tego samodzielnie. Plus pełna jurysdykcja UE.

Często zadawane pytania

Zobacz wszystkie często zadawane pytania

Czy region UE Supabase (Frankfurt, Irlandia) jest wystarczający dla RODO?

Rezydencja tak, suwerenność nie. Supabase Inc. ma siedzibę w USA, a regiony Frankfurt/Ireland działają na AWS - również pod jurysdykcją USA. Dla analiz Schrems II, obie warstwy są narażone.

Czy samodzielnie hostowany Supabase ma pełną parytet funkcji?

Tak, dla podstawowego stosu: Postgres, Auth (GoTrue), Storage, Edge Functions, Realtime, Studio, PostgREST. Klient supabase-js działa identycznie. Funkcje niedostępne w wersji self-hosted: funkcje płatnych planów, takie jak interfejs zarządzania zespołem i zintegrowane panele logowania (te budujesz sam za pomocą Loki + Grafana na infrastrukturze w UE).

Jak złożony operacyjnie jest self-hosted Supabase?

W przypadku produkcji z jednym środowiskiem wystarczy jedna niewielka maszyna wirtualna z Docker Compose, co jest operacyjnie łatwe do zarządzania dla doświadczonego zespołu inżynierskiego. Dla środowisk wielo-środowiskowych lub konfiguracji HA, Kubernetes z Helm chart to wzorzec produkcyjny; obsługujemy to dla klientów.

Czy klient supabase-js wymaga zmian w kodzie?

Tylko jedno: URL wskazuje na Twoją instancję self-hosted zamiast na `*.supabase.co`. Zasady RLS, przepływy auth, adresy URL storage, subskrypcje realtime - wszystko bez zmian.

A co z odpowiednikami zarządzanego Supabase w UE?

Pojawiają się oferty z siedzibą w UE (Supascale, Supafast - obie na wczesnym etapie), ale gotowym do produkcji rozwiązaniem jest samodzielnie hostowany Supabase zarządzany przez partnera z UE. Wdrażamy i obsługujemy dokładnie ten model.

Ile trwa wyjście z Supabase?

Dla projektu z jednym środowiskiem (jeden Postgres, podstawowa autoryzacja, kilka bucketów): 1-2 tygodnie. Dla konfiguracji wielośrodowiskowych lub z dużą ilością danych: 3-6 tygodni. Migracja jest technicznie czysta, ponieważ wszystko opiera się na open-source.

Zaplanuj wyjście z Supabase.

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ę