---
title: "Plurabase vs Supabase and Vercel"
description: "What Plurabase shares with Supabase and Vercel, what it lacks, and how to move an application between them. Plurabase is a private pilot."
slug: "compare"
locale: "en"
group: "start"
order: 3
last_reviewed: 2026-10-26
---

# Plurabase vs Supabase and Vercel

Plurabase combines two things that are usually separate: a backend made of Supabase's open-source services and a static frontend host. Supabase and Vercel are generally available commercial services; Plurabase is a private pilot (see [facts](/docs/facts/)). Facts about Supabase and Vercel below come from their public documentation as of 2026-10-18; check their sites for current plans, prices, SLAs and compliance.

## At a glance

| Topic | Plurabase today | Supabase | Vercel |
| --- | --- | --- | --- |
| Availability | Private pilot over Tailscale; not open to the public | Generally available | Generally available |
| Main purpose | Static frontend plus a per-project backend in one project | Postgres backend platform | Frontend cloud |
| Database | PostgreSQL 17.6 per project, RLS, PostgREST | Postgres per project, RLS, PostgREST | Through Marketplace integrations |
| Auth for your app's users | GoTrue email and password | Supabase Auth (GoTrue) with email, OAuth, phone and SSO | Not built in |
| Storage | Supabase Storage buckets | Supabase Storage | Vercel Blob |
| Realtime | Postgres Changes | Postgres Changes, Broadcast, Presence | Not built in |
| Backend functions | Edge Functions on one host; local imports only | Edge Functions, globally distributed | Vercel Functions |
| Frontend hosting | Static ZIP upload (Sites) | Backend only; frontends are hosted elsewhere | Core product |
| Server-side rendering | No | Not applicable | Yes |
| Git deploys and previews | In development and planned | Not applicable | Yes |
| Custom domains | Planned | Available for the project API | Yes |
| Backups | In development; none running | Managed backups; point-in-time recovery as an add-on | Not applicable |
| Coding agents | Project-scoped MCP, bearer token, private network | Official MCP server with OAuth and per-project scoping | Official MCP server with OAuth |
| Prices and SLA | None | Published plans | Published plans |

## What is equivalent to Supabase

Each Plurabase project runs the same open-source services that self-hosted Supabase runs, pinned to the images of Supabase's release `self-hosted/v0.8.2` (PostgreSQL 17.6, GoTrue, PostgREST, Realtime, Storage API and Edge Runtime), plus a Studio built from Supabase's source with Plurabase changes. Code written against `@supabase/supabase-js` v2 for tables, RPC, Row Level Security, email and password Auth, Storage buckets and Postgres Changes works against a Plurabase project. SQL, RLS policies and Deno Edge Function source are standard and carry over.

## What is not equivalent to Supabase

- No Supabase Cloud platform features: managed backups, point-in-time recovery, branching, read replicas, log drains, global Edge Functions, usage-based plans.
- No compatibility with the Supabase Management API or the Supabase CLI. Plurabase has its own control plane and its own [MCP server](/docs/agent-quickstart/).
- No direct PostgreSQL connections from outside the host.
- Emails to your application's users are not delivered outside the pilot host; OAuth, phone and SSO providers are not configured.
- Edge Functions cannot import remote npm or jsr packages.

## What is equivalent to Vercel

Only static hosting. A Site serves a prebuilt static frontend (HTML, CSS, JavaScript and assets) from a ZIP, with releases you can roll back. Each release is served under its own path prefix with a strict Content Security Policy, so a build fits only if the URLs of its own files are relative (`./`) and it has no inline scripts or styles. A Vite single-page app with `base: './'` can meet these rules, but no Vite build has run on Sites yet. Next.js static export and Astro output do not fit. Details: [framework builds](/docs/hosting-sites/#framework-builds).

## What is not equivalent to Vercel

- No server-side rendering, Node.js servers, Next.js Server Actions, middleware or ISR. These are deferred and not scheduled.
- No Git deploys yet (in development), no preview deployments and no custom domains (planned).
- No global CDN: Sites are served from the pilot host.
- No SPA fallback: a deep link to a client-side route returns 404, so use hash-based routing or link to `index.html`.
- Site code runs on an opaque origin: no cookies, `localStorage` or service workers, so users sign in again after a reload.

## Moving from Supabase to Plurabase

During the pilot a migration is done with the operator, not by a self-service tool. A read-only inventory lists what the source project uses; the database is moved with a dump and restore; Storage objects are copied and counted; Edge Functions are redeployed with their secrets. Auth users travel with the database, but existing sessions end because the JWT secret changes. Details: [migration in and out](/docs/migration/).

## Moving from Vercel to Plurabase Sites

1. Produce a static single-page build whose asset URLs are relative, for example `vite build` with `base: './'`. Next.js with `output: 'export'` is not supported. Check the build against [framework builds](/docs/hosting-sites/#framework-builds) before uploading: each Site accepts two uploads in its lifetime.
2. Move any server-side logic into Edge Functions or keep it on another host.
3. Read the backend from `./__simplybase/config.json` as shown in [frontend hosting](/docs/hosting-sites/).
4. Zip the build with `index.html` at the root and upload it in the console.

## Moving from Plurabase to Supabase or another host

Because the components match, a Plurabase project's PostgreSQL dump, Storage objects and Edge Function source restore into Supabase Cloud, self-hosted Supabase or any PostgreSQL 17 server. Self-service export exists only as code (no console button, not enabled on the pilot host); ask the operator. The Site's ZIP is an ordinary static build that any static host serves.

## When to choose something else

- Choose Supabase if you need a backend for production today, managed backups, point-in-time recovery, branching or read replicas.
- Choose Vercel if your frontend needs server-side rendering, previews, Git deploys or a global CDN today.
- Choose Plurabase only if you are in the pilot and want to try a frontend and a Supabase-style backend managed as one project.