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). 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.
- 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.
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,
localStorageor 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.
Moving from Vercel to Plurabase Sites
- Produce a static single-page build whose asset URLs are relative, for example
vite buildwithbase: './'. Next.js withoutput: 'export'is not supported. Check the build against framework builds before uploading: each Site accepts two uploads in its lifetime. - Move any server-side logic into Edge Functions or keep it on another host.
- Read the backend from
./__simplybase/config.jsonas shown in frontend hosting. - Zip the build with
index.htmlat 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.