Alternativa solo UE a Supabase.

Supabase es la alternativa open-source a Firebase: Postgres alojado + Auth + Storage + Edge Functions + Realtime con una experiencia de desarrollador muy pulida. Supabase Inc. es una corporación estadounidense de Delaware; las regiones UE (Fráncfort, Irlanda, Londres, París) se ejecutan sobre infraestructura de AWS bajo control jurisdiccional de EE.UU. tanto de Supabase como de AWS. La buena noticia: Supabase es open-source. Puedes autoalojar todo el stack en infraestructura de la UE con paridad total de funcionalidades - esa es la alternativa soberana que desplegamos para los clientes.

Estados Unidos Pila de reemplazo, solo UE 10 servicios mapeados
Agendar una llamada Escanee primero su dominio
Proveedor
Supabase
Sede
San Francisco, CA
Jurisdicción
Estados Unidos
Régimen legal
CLOUD Act, FISA 702

"Región UE" no es soberanía. Cuatro preguntas lo deciden.

La residencia de datos dice dónde están los bits. La soberanía dice qué sistema legal puede obligar al acceso. La respuesta debe sostenerse en los cuatro puntos, o la pila no es soberana.

Residencia

¿Dónde se almacenan físicamente los datos?

No "en la nube": qué centro de datos, en qué país, bajo qué jurisdicción.

Subprocesadores

¿Quién más está en su ruta de datos?

Cada proveedor que toca los datos: el CDN, el relay de correo, el rastreador de errores, el pipeline de analítica.

Jurisdicción

¿Qué leyes pueden obligar a la divulgación?

Un proveedor con sede en EE. UU. está sujeto a la FISA 702 y a la CLOUD Act, aunque los datos estén en Fráncfort.

Custodia de claves

¿Quién posee realmente las claves de cifrado?

Si el proveedor cloud posee tanto los datos como las claves, puede leerlos, con independencia de cualquier DPA.

No cumple AWS · Azure · GCP · Región de la UE

Falla en jurisdicción y custodia de claves.

Bits en la UE, matriz con sede en EE. UU., subprocesadores estadounidenses en la ruta por defecto, claves gestionadas por el proveedor.

Cumple Stack gestionado por Binadit

Pasa en los cuatro.

Alojado en la UE sobre infraestructura con sede europea. Cero subprocesadores estadounidenses en la ruta por defecto. Claves del cliente o de un KMS europeo. Nombrados en su DPA del Artículo 28.

Por qué los equipos están saliendo Supabase

Las migraciones fuera de Supabase que hemos gestionado surgen de un mismo desencadenante: un SaaS B2B que eligió Supabase por su DX, creció hasta tener clientes enterprise, y descubrió que "Supabase Fráncfort en AWS Irlanda" son dos capas de procesadores bajo jurisdicción de EE.UU. que no superan el análisis de Schrems II. El propio equipo de Supabase ha hablado públicamente de las limitaciones de soberanía de datos en su blog. Alojar Supabase por cuenta propia en infraestructura de la UE preserva toda la DX (el mismo cliente supabase-js funciona igual) mientras se pasa a jurisdicción plena de la UE.

Supabase servicios y sus equivalentes solo en la UE

Una migración no es "cambiar una caja por otra". El mapeo a continuación es lo que ejecutamos para los clientes que dejan Supabase por motivos de Schrems II: jurisdicción europea completa, sin matriz estadounidense en la ruta de datos.

Postgres (managed)

Lo que usamos en su lugar
Binadit Managed Cloud Platform. PostgreSQL o MySQL con Patroni para failover y pgBackRest para recuperación point-in-time.
Nota de ingeniería
La replicación streaming nos permite hacer la transición con segundos de inactividad en lugar de una ventana de mantenimiento, y las restauraciones se prueban de forma programada en lugar de darse por sentadas.

Auth (GoTrue)

Lo que usamos en su lugar
Binadit Managed Cloud Platform. Keycloak o Authentik como proveedor de identidad, con OIDC y SAML.
Nota de ingeniería
GoTrue es parte del stack abierto de Supabase; el autoalojamiento conserva la autenticación basada en JWT con inicio de sesión social, magic links y MFA.

Storage (S3-compatible)

Lo que usamos en su lugar
Binadit Managed Cloud Platform. MinIO o Ceph RGW, compatible con S3.
Nota de ingeniería
Supabase Storage es una capa de servicio sobre almacenamiento compatible con S3; funciona con cualquier backend S3 de la UE.

Edge Functions (Deno)

Lo que usamos en su lugar
Binadit Managed Cloud Platform. Knative u OpenFaaS en tu clúster de Kubernetes.
Nota de ingeniería
Las Edge Functions son entornos de ejecución Deno; el equivalente autoalojado funciona en cualquier plataforma de contenedores de la UE.

Realtime (Postgres CDC)

Lo que usamos en su lugar
Binadit Managed Cloud Platform. Replicación lógica de PostgreSQL hacia una capa websocket, o NATS para fan-out.
Nota de ingeniería
Realtime es open-source; el autoalojamiento preserva el pub/sub basado en WebSocket.

Vector embeddings (pgvector)

Lo que usamos en su lugar
Binadit Managed Cloud Platform. pgvector sobre PostgreSQL, o Qdrant para conjuntos de embeddings más grandes.
Nota de ingeniería
Para cargas de trabajo vectoriales dedicadas, Qdrant Cloud EU es una alternativa soberana por defecto.

Studio (admin UI)

Lo que usamos en su lugar
Binadit DevOps & Support. pgAdmin o Metabase para el acceso a datos, con Grafana para las vistas operativas.
Nota de ingeniería
Studio forma parte de la distribución autoalojada.

Database backups

Lo que usamos en su lugar
Binadit Managed Cloud Platform. restic y pgBackRest para los datos, Velero para el estado de Kubernetes, hacia almacenamiento aislado en la UE.
Nota de ingeniería
WAL-G con backend de object storage en la UE es el patrón de nivel producción.

API (PostgREST)

Lo que usamos en su lugar
Binadit Managed Cloud Platform. Traefik o Kong, con rate limiting y OIDC en el edge.
Nota de ingeniería
PostgREST es open-source; el autoalojamiento preserva la generación de la API REST.

CLI / Migrations

Lo que usamos en su lugar
Binadit DevOps & Support. kubectl, Terraform y GitLab CI, con wrappers específicos del proyecto donde resulten útiles.
Nota de ingeniería
El CLI de Supabase soporta `--db-url` para apuntar a instancias autoalojadas.

Cómo migramos desde Supabase

Una migración típica de mid-market se desarrolla en tres fases. Los números a continuación asumen un equipo de ingeniería de 6 a 10 personas y un stack de aplicación moderadamente complejo.

  1. Días 1-5

    Despliegue autogestionado de Supabase

    Desplegar el stack de Supabase autoalojado en Binadit (Docker Compose o Kubernetes). Configurar proveedores de auth, backend de storage, runtime de Edge Functions. Configurar monitoring y backups.

  2. Días 6-14

    Base de datos + migración de auth

    Volcado y restauración de Postgres a instancia autoalojada. Cuentas de usuario migradas mediante exportación de datos del proveedor de autenticación. Buckets de almacenamiento replicados. Edge Functions redesplegadas.

  3. Semanas 2-3

    Transición de la aplicación

    Configuración de la aplicación actualizada para apuntar a la URL de Supabase autohospedado. Mismo cliente supabase-js, mismas políticas RLS, mismos flujos de autenticación. Transición con una ventana de verificación.

Un despliegue autogestionado de Supabase en una sola VM pequeña reemplaza a Supabase Pro a 25 $ por proyecto al mes más el uso por proyecto. Para cargas de trabajo con múltiples proyectos, el ahorro se multiplica: un plan de equipo típico de Supabase (599 $/mes) pasa a costar entre 40 y 100 €/mes en infraestructura pura más la tarifa del partner gestionado si no quieres operarlo tú mismo. Además, jurisdicción 100% de la UE.

Preguntas frecuentes

Ver todas las preguntas frecuentes

¿Es suficiente la región de la UE de Supabase (Fráncfort, Irlanda) para el RGPD?
Residencia sí, soberanía no. Supabase Inc. tiene sede en EE. UU., y las regiones de Frankfurt/Irlanda corren sobre AWS - también bajo jurisdicción de EE. UU. Para análisis Schrems II, ambas capas quedan expuestas.
¿Supabase autoalojado tiene paridad total de funciones?
Sí, para la pila principal: Postgres, Auth (GoTrue), Storage, Edge Functions, Realtime, Studio, PostgREST. El cliente supabase-js funciona de forma idéntica. Las funcionalidades que no están disponibles en autoalojado: características de pago como la interfaz de gestión de equipos y los paneles de logging integrados (esos se construyen con Loki + Grafana en infraestructura de la UE).
¿Qué tan compleja operacionalmente es Supabase autoalojado?
Para producción en un solo entorno, una única VM modesta con Docker Compose es suficiente y operativamente manejable para un equipo de ingeniería con experiencia. Para configuraciones multi-entorno o de alta disponibilidad (HA), Kubernetes con Helm chart es el patrón de producción; nosotros operamos esto para clientes.
¿El cliente supabase-js necesita cambios de código?
Solo una: la URL apunta a tu instancia autogestionada en lugar de `*.supabase.co`. Las políticas RLS, los flujos de auth, las URLs de storage, las suscripciones en tiempo real: todo permanece igual.
¿Qué pasa con los equivalentes de Supabase gestionado en la UE?
Existen ofertas emergentes con sede en la UE (Supascale, Supafast, ambas en etapa temprana), pero la respuesta lista para producción es Supabase autoalojado y gestionado por un partner de la UE. Nosotros desplegamos y operamos exactamente este patrón.
¿Cuánto tiempo toma una salida de Supabase?
Para un proyecto de un solo entorno (un Postgres, autenticación básica, algunos buckets): 1-2 semanas transcurridas. Para configuraciones multientorno o de gran volumen de datos: 3-6 semanas. La migración es mecánicamente limpia porque todo es open-source upstream.

Planifique su salida de Supabase.

Llamada de alcance de 30 minutos. Mapeamos su stack frente a alternativas solo UE, estimamos el esfuerzo de migración y le decimos si es la decisión correcta.

Agendar una llamada Comparar otro proveedor