--- title: "Plurabase frente a Supabase y Vercel" description: "Qué comparte Plurabase con Supabase y Vercel, qué le falta y cómo mover una aplicación entre ellos. Plurabase es un piloto privado." slug: "compare" locale: "es" group: "start" order: 3 last_reviewed: 2026-10-26 --- # Plurabase frente a Supabase y Vercel Plurabase junta dos cosas que suelen ir por separado: un backend hecho con los servicios open source de Supabase y un hosting de frontend estático. Supabase y Vercel son servicios comerciales disponibles para el público; Plurabase es un piloto privado (consulta los [datos](/es/docs/facts/)). Lo que se dice aquí de Supabase y Vercel viene de su documentación pública al 2026-10-18; revisa sus sitios para conocer planes, precios, SLA y cumplimiento vigentes. ## De un vistazo | Tema | Plurabase hoy | Supabase | Vercel | | --- | --- | --- | --- | | Disponibilidad | Piloto privado por Tailscale; no abierto al público | Disponible para el público | Disponible para el público | | Propósito principal | Frontend estático y backend por proyecto en un solo proyecto | Plataforma de backend Postgres | Nube de frontend | | Base de datos | PostgreSQL 17.6 por proyecto, RLS, PostgREST | Postgres por proyecto, RLS, PostgREST | Mediante integraciones del Marketplace | | Auth para los usuarios de tu app | GoTrue con correo y contraseña | Supabase Auth (GoTrue) con correo, OAuth, teléfono y SSO | No incluido | | Storage | Buckets de Supabase Storage | Supabase Storage | Vercel Blob | | Realtime | Postgres Changes | Postgres Changes, Broadcast, Presence | No incluido | | Funciones de backend | Edge Functions en un host; solo imports locales | Edge Functions distribuidas globalmente | Vercel Functions | | Hosting de frontend | Subida de ZIP estático (Sites) | Solo backend; el frontend se aloja en otro lugar | Producto principal | | Renderizado en servidor | No | No aplica | Sí | | Despliegues desde Git y vistas previas | En desarrollo y planificados | No aplica | Sí | | Dominios propios | Planificado | Disponible para la API del proyecto | Sí | | Backups | En desarrollo; ninguno en funcionamiento | Backups gestionados; recuperación a un punto en el tiempo como complemento | No aplica | | Agentes de programación | MCP acotado al proyecto, token bearer, red privada | Servidor MCP oficial con OAuth y alcance por proyecto | Servidor MCP oficial con OAuth | | Precios y SLA | Ninguno | Planes publicados | Planes publicados | ## Qué es equivalente a Supabase Cada proyecto de Plurabase ejecuta los mismos servicios open source que Supabase self-hosted, fijados a las imágenes de la versión de Supabase `self-hosted/v0.8.2` (PostgreSQL 17.6, GoTrue, PostgREST, Realtime, Storage API y Edge Runtime), más un Studio compilado desde el código de Supabase con cambios de Plurabase. El código escrito con `@supabase/supabase-js` v2 para tablas, RPC, Row Level Security, Auth con correo y contraseña, buckets de Storage y Postgres Changes funciona contra un proyecto de Plurabase. El SQL, las políticas RLS y el código Deno de las Edge Functions son estándar y se pueden llevar a otro lado. ## Qué no es equivalente a Supabase - No hay funciones de la plataforma Supabase Cloud: backups gestionados, recuperación a un punto en el tiempo, branching, réplicas de lectura, log drains, Edge Functions globales, planes por consumo. - No es compatible con la Management API ni con la CLI de Supabase. Plurabase tiene su propio plano de control y su propio [servidor MCP](/es/docs/agent-quickstart/). - No hay conexiones directas a PostgreSQL desde fuera del host. - Los correos a los usuarios de tu aplicación no salen del host del piloto; los proveedores OAuth, teléfono y SSO no están configurados. - Las Edge Functions no pueden importar paquetes remotos de npm o jsr. ## Qué es equivalente a Vercel Solo el hosting estático. Un Site sirve un frontend estático precompilado (HTML, CSS, JavaScript y recursos) desde un ZIP, con versiones que se pueden revertir. Cada versión se sirve bajo su propio prefijo de ruta con una Content Security Policy estricta, así que un build encaja solo si las URLs de sus propios archivos son relativas (`./`) y no tiene scripts ni estilos en línea. Una app de una sola página con Vite y `base: './'` puede cumplir estas reglas, pero todavía no se ha ejecutado ningún build de Vite en Sites. El export estático de Next.js y la salida de Astro no encajan. Detalles: [builds de frameworks](/es/docs/hosting-sites/#builds-de-frameworks). ## Qué no es equivalente a Vercel - No hay renderizado en servidor, servidores Node.js, Server Actions de Next.js, middleware ni ISR. Están pospuestos y sin fecha. - Todavía no hay despliegues desde Git (en desarrollo), ni vistas previas ni dominios propios (planificados). - No hay CDN global: los Sites se sirven desde el host del piloto. - No hay fallback de SPA: un enlace directo a una ruta del cliente devuelve 404, así que usa rutas con hash o enlaza a `index.html`. - El código del Site corre en un origen opaco: sin cookies, `localStorage` ni service workers, así que los usuarios vuelven a iniciar sesión al recargar. ## De Supabase a Plurabase Durante el piloto, una migración se hace con el operador, no con una herramienta de autoservicio. Un inventario de solo lectura enumera lo que usa el proyecto de origen; la base de datos se mueve con un volcado y una restauración; los objetos de Storage se copian y se cuentan; las Edge Functions se vuelven a desplegar con sus secretos. Los usuarios de Auth viajan con la base de datos, pero las sesiones existentes terminan porque cambia el secreto JWT. Detalles: [migración de entrada y salida](/es/docs/migration/). ## De Vercel a Plurabase Sites 1. Genera un build estático de una sola página con URLs de recursos relativas, por ejemplo `vite build` con `base: './'`. Next.js con `output: 'export'` no está soportado. Revisa el build con [builds de frameworks](/es/docs/hosting-sites/#builds-de-frameworks) antes de subirlo: cada Site acepta dos subidas durante toda su vida. 2. Pasa la lógica de servidor a Edge Functions o déjala en otro host. 3. Lee el backend desde `./__simplybase/config.json` como se muestra en [hosting de frontend](/es/docs/hosting-sites/). 4. Comprime el build con `index.html` en la raíz y súbelo en la consola. ## De Plurabase a Supabase u otro proveedor Como los componentes coinciden, el volcado de PostgreSQL, los objetos de Storage y el código de las Edge Functions de un proyecto de Plurabase se restauran en Supabase Cloud, Supabase self-hosted o cualquier servidor PostgreSQL 17. La exportación por autoservicio existe solo como código (sin botón en la consola, no habilitada en el host del piloto); pídela al operador. El ZIP del Site es un build estático común que sirve cualquier hosting estático. ## Cuándo elegir otra opción - Elige Supabase si hoy necesitas un backend para producción, backups gestionados, recuperación a un punto en el tiempo, branching o réplicas de lectura. - Elige Vercel si hoy tu frontend necesita renderizado en servidor, vistas previas, despliegues desde Git o una CDN global. - Elige Plurabase solo si estás en el piloto y quieres probar un frontend y un backend estilo Supabase gestionados como un solo proyecto.