--- title: "Compatibilidad con Supabase" description: "Qué servicios de Supabase ejecuta cada proyecto de Plurabase, con versiones, qué se ha probado con supabase-js v2 y qué falta." slug: "compatibility" locale: "es" group: "platform" order: 1 last_reviewed: 2026-10-21 --- # 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](/es/docs/facts/#estados). | Servicio | Imagen | | --- | --- | | Base de datos | `supabase/postgres` 17.6.1.136 (PostgreSQL 17.6) | | Auth | `supabase/gotrue` v2.196.0 | | REST | `postgrest/postgrest` v14.17 | | Realtime | `supabase/realtime` v2.134.10 | | Storage | `supabase/storage-api` v1.74.0 | | Edge Functions | `supabase/edge-runtime` v1.76.2 | | Pooler | `supabase/supavisor` 2.9.12 | | Studio | Compilado desde el código de Supabase con cambios de Plurabase | ## 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](/es/docs/security-status/#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](/es/docs/security-status/). ## 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](/es/docs/facts/#lo-que-plurabase-no-ofrece).