Compatibilidad con Supabase

Cada proyecto de Plurabase ejecuta su propia copia de los servicios open source de Supabase, fijados a las imágenes de la versión self-hosted de Supabase self-hosted/v0.8.2 (commit 564eab8), salvo Studio, que se compila desde el código de Supabase con cambios de Plurabase. Por eso compatibilidad significa compatibilidad con Supabase self-hosted en esas versiones, probada en un laboratorio privado con @supabase/supabase-js v2. No significa paridad con Supabase Cloud. Los estados usan las palabras definidas en la página de datos.

Base de datos y REST#

Estado: Disponible en el piloto (database.postgres)

Estado: Disponible en el piloto (database.rest)

Tablas, vistas, claves foráneas, enums, funciones y triggers funcionan como en PostgreSQL 17.6. PostgREST sirve CRUD y RPC; Row Level Security se aplica a las peticiones hechas con la clave publicable y JWT de usuario. No se ofrecen conexiones directas a PostgreSQL desde fuera del host. Conserva los esquemas graphql y graphql_public: PostgREST los necesita al arrancar.

Studio#

Estado: Disponible en el piloto (database.studio)

Los owners y admins de un proyecto abren su Supabase Studio (Table Editor, SQL Editor, Auth, Storage, Functions) desde la consola de Plurabase. El acceso a Studio exige la identidad de Tailscale del piloto, una sesión de la consola y un permiso de Studio para esa sesión, y añade por su cuenta la credencial HTTP Basic de Studio. En el host del piloto los owners y admins también pueden ver esa credencial en la consola, y es de larga duración; la rotación de claves, escrita y no desplegada, deja de mostrarla y la rota con las claves del proyecto (consulta rotación de claves). Studio actúa con autoridad administrativa: su SQL omite RLS. Prueba tus políticas con tokens de usuario, no desde Studio.

Auth para los usuarios de tu aplicación#

Estado: Disponible en el piloto (auth.email-password)

Estado: Planificado (auth.providers)

El registro, inicio de sesión, renovación de token y cierre de sesión con correo y contraseña funcionan con GoTrue. Los correos de confirmación y recuperación para tus usuarios van a un buzón de captura en el host del piloto y no salen de él. Los proveedores OAuth, el SMTP propio, el OTP por teléfono y SAML SSO no están configurados. El registro de cuentas de la plataforma Plurabase es un sistema aparte, descrito en seguridad.

Storage#

Estado: Disponible en el piloto (storage.buckets)

Los buckets privados y públicos, las políticas RLS por ruta, la subida, la descarga y las URLs firmadas con caducidad funcionan con supabase-js. El protocolo S3, las subidas reanudables y la transformación de imágenes no se han verificado.

Realtime#

Estado: Disponible en el piloto (realtime.changes)

Los Postgres Changes llegan por WebSocket para las tablas añadidas a la publicación supabase_realtime. Broadcast y Presence no se han verificado.

Edge Functions#

Estado: Disponible en el piloto (functions.edge)

Las funciones usan Deno.serve, corren en el host del piloto y pueden leer secretos cifrados del proyecto. Una función puede importar sus propios archivos locales y versiones fijadas de @supabase/supabase-js v2 y @supabase/server; no se descargan imports remotos de npm ni jsr. Un despliegue indica la revisión que reemplaza, así que dos despliegues no se sobrescriben en silencio. No hay red edge global.

Proyectos del plan compartido#

Estado: En desarrollo (projects.shared)

Un proyecto del plan compartido ejecuta su propia base de datos y sus servicios de Auth y REST en un host que comparte con otros proyectos, y usa los servicios de Realtime y Storage de ese host. Studio, Edge Functions en una microVM por proyecto, los logs de funciones, la transformación de imágenes y los webhooks de base de datos existen como código para estos proyectos; nada de eso se ha ejecutado en un host. Hay tres cosas que un proyecto compartido no ofrece, y sus peticiones reciben un 409 que dice por qué:

• Logs de Postgres, API y Auth: todavía no hay una canalización de logs que los recoja para proyectos compartidos.
• El protocolo S3: el Storage compartido no emite claves de acceso S3.
• Subidas reanudables (TUS): el Storage compartido solo acepta peticiones de buckets y objetos, así que los archivos se suben con la subida estándar, de hasta 16 MiB.

No disponible#

Estado: Planificado (database.branching)

Estado: En desarrollo (database.pitr)

No hay branching, réplicas de lectura, recuperación a un punto en el tiempo, log drains, la Management API de Supabase ni la CLI de Supabase. La recuperación a un punto en el tiempo está escrita (archivado de WAL, ADR-0031) pero no está activada en el host del piloto. La lista completa está en la página de datos.