¿Cumple Supabase el RGPD? Dónde viven de verdad sus datos

Soy Denys, ingeniero full-stack y de IA, y la mayoría de las apps que construyo o arreglo corren sobre Supabase. Los clientes europeos hacen dos preguntas antes que cualquier otra: ¿cumple Supabase el RGPD? y ¿dónde están los datos? Este artículo responde a ambas con los propios documentos de Supabase y de Lovable, leídos el 29 de octubre de 2026, y con los comandos que uso para comprobar un proyecto.

¿Cumple Supabase el RGPD?

La guía del RGPD de Supabase lo plantea como responsabilidad compartida: Supabase protege la infraestructura, y usted es responsable del tratamiento de datos de su aplicación, de los flujos de consentimiento y de los controles de acceso. En términos del RGPD, Supabase es su encargado del tratamiento para los datos que guarda, y su Data Processing Addendum es el contrato que lo dice. El mismo documento nombra a Supabase responsable del tratamiento para una categoría, los datos de uso que recopila para operar la plataforma.

Dos partes de ese DPA importan en la práctica:

• Región. Cuando usted indica a Supabase que trate los datos en una región, los almacena y trata principalmente allí, salvo que la ley, sus propias instrucciones o el servicio que pidió exijan otra cosa.
• Subencargados. Usted autoriza de antemano la lista de subencargados de Supabase, y Supabase avisa con 30 días de antelación antes de cambiarla. Puede suscribirse a esos cambios en la misma página. La lista incluye a AWS y Cloudflare para el alojamiento, y proveedores de servicios para soporte, monitorización de errores y mensajes a los usuarios de la cuenta.

¿Dónde guarda Supabase sus datos?

La FAQ de residencia de datos y la página de regiones lo reparten así:

Parte de su proyecto	Dónde se trata
Base de datos Postgres y sus copias	La región de AWS que eligió
Auth (usuarios, sesiones)	La región que eligió
Archivos de Storage en origen	La región que eligió
Caché de la CDN de Storage	A nivel global, en caché de Cloudflare
Edge Functions	En el edge más cercano a quien llama, salvo que las fije a una región
Logs y telemetría de la plataforma	Fuera de su región; los logs se guardan en centros de datos de la UE
Acceso del soporte	Un equipo de soporte global, cuando usted pide ayuda o durante un incidente de seguridad, registrado
Datos de su cuenta y de facturación	Sistemas centrales de Supabase; aquí Supabase es el responsable del tratamiento

La FAQ responde directamente a la pregunta cruda: Supabase no garantiza que sus datos nunca salgan de la región. Su base de datos y sus copias se quedan; las cuatro categorías del final de la tabla pueden salir.

¿Qué regiones de Supabase están en la UE?

Cuatro regiones concretas están dentro de la UE: West EU (Irlanda) eu-west-1, West EU (París) eu-west-3, Central EU (Fráncfort) eu-central-1 y North EU (Estocolmo) eu-north-1. Londres eu-west-2 y Zúrich eu-central-2 están en Europa y tienen decisiones de adecuación del RGPD, pero no son Estados miembros de la UE.

Esa distinción importa al crear el proyecto. La opción genérica “Europe” deja que Supabase elija una región europea disponible según la capacidad, y la guía de regiones advierte de que puede ser Londres o Zúrich. Si su contrato o su cliente dice “los datos se quedan en la UE”, elija una región concreta de la UE. Un detalle más si usa Edge Functions regionales: la página de regiones dice que fijar una función a una región no está disponible en Ohio ni en Estocolmo.

¿Cómo se comprueba la región de su proyecto?

En el panel, la región aparece en los ajustes del proyecto. Desde una terminal, la CLI de Supabase lista todos los proyectos a los que tiene acceso con su región:

supabase projects list
supabase projects list -o json   # each project has a "region" field, e.g. "eu-west-1"

Lo ejecuté en mi propia cuenta con la CLI 2.109.1: cada proyecto devolvió su código de región de AWS, así que un vistazo rápido basta para ver si alguno está fuera de la UE.

¿Se puede cambiar? No. La nota de resolución de problemas de Supabase dice que un proyecto está atado a su región a nivel de infraestructura. Moverlo significa crear un proyecto nuevo en la región de destino y migrar a él, y después actualizar la URL de la API y las claves en la app y copiar a mano los secretos del inicio de sesión de terceros. Transferir un proyecto a otra organización tampoco cambia la región.

¿Lovable Cloud cumple el RGPD?

Una app de Lovable Cloud ejecuta su backend con el mismo modelo, así que valen las mismas preguntas, con los ajustes de Lovable por delante. Según la documentación del backend, la documentación de la base de datos y la página del DPA de Lovable:

• La región es una de Americas, Europe o Asia Pacific, elegida al activar el backend. Un valor por defecto del espacio de trabajo fijado por un administrador prevalece (planes Business y Enterprise). Si no, Lovable usa su propio ajuste “where project data is stored” y, sin él, la región más cercana a usted.
• Puede que nunca la vea. Con Enable Cloud en “Always allow”, Lovable crea el backend en esa región sin preguntar. Solo “Ask each time” muestra antes la región.
• No se puede cambiar. Lovable dice claramente que la región de un proyecto no puede cambiarse y que un proyecto existente no puede moverse.
• Compruébela en More → Database → Manage → Settings, en la fila Database location, por ejemplo “Europe (Frankfurt)”.
• El sitio en sí se sirve globalmente, sea cual sea la región; la región cubre solo el backend.
• Las peticiones de IA van aparte. Mantener en la UE las peticiones a modelos de IA es un ajuste llamado EU inference, en los espacios de trabajo Enterprise.
• El DPA está incluido en los planes Business y Enterprise.

Así que si activó el backend trabajando desde fuera de Europa, sin un ajuste propio, el backend puede estar en otra región, y con “Always allow” activado Lovable no pregunta. Revise la fila Database location antes de que se registre su primer usuario real.

Lo que la región no resuelve

La propia guía de Supabase lo dice: elegir una región es un control de ubicación de los datos y no hace por sí solo que una aplicación cumpla el RGPD. Los fallos que encuentro con más frecuencia están en la app, no en la plataforma:

1. Datos personales legibles por cualquiera. Una tabla con RLS desactivado, o con una política que permite todas las filas, sirve nombres y correos a quien tenga la clave pública. La auditoría de seguridad de Supabase gratuita marca las tablas sin RLS, las políticas que permiten todas las filas y las columnas de aspecto sensible legibles por visitantes anónimos.
2. Cuentas creadas con la dirección de otra persona. Con la confirmación de correo desactivada, cualquiera puede registrarse con una dirección que no es suya.
3. Archivos en buckets públicos. Un bucket público sirve cada archivo a cualquiera que tenga su URL, y la CDN lo cachea en todo el mundo.
4. Encargados que añadió usted. Cada servicio de correo, SMS, IA o analítica que llaman sus Edge Functions es su encargado, no el de Supabase, y necesita su propio contrato.
5. Borrado y conservación. Una solicitud de supresión falla si las claves foráneas impiden borrar a un usuario que escribió contenido, y los logs que guardan direcciones para siempre son un problema de conservación.

Repaso los dos últimos, y cuatro más, en la sección de RGPD de mi lista de seguridad para apps Lovable. Para saber qué certifica Supabase más allá del RGPD, vea ¿es seguro Supabase?. Este artículo no es asesoramiento legal; su delegado de protección de datos o su abogado decide qué necesita su tratamiento.