How do you migrate from Supabase to Powabase?

What carries over from Supabase unchanged?

Most of it, because we run the same open-source services Supabase is built on. PostgREST serves your tables with the same filter operators, embeds, and Prefer headers. GoTrue serves auth at the same /auth/v1 endpoints with the same JWT shape and OAuth providers. Storage keeps the same bucket and object model, resumable uploads, and signed URLs. Realtime has the same Broadcast, Presence, and Postgres Changes channels. Row Level Security works identically, including auth.uid(), auth.jwt(), and auth.role(), so your policies move as plain SQL. The @supabase/supabase-js client works against Powabase for the database, auth, storage, and realtime, which means most frontend code only needs a new project URL and anon key. pgvector is installed on every project, so if you built RAG yourself on vector columns, those tables and queries keep working. On top of that, Powabase adds the AI layer on the same project, with knowledge bases that extract and index documents on upload, plus agents, orchestrations, and workflows. For a side-by-side of the two platforms, see Powabase vs Supabase.

What should you plan before you migrate?

Take a short inventory first, so the migration runs as a checklist. List the schemas you own, usually public plus any custom ones, and leave the platform-managed schemas (auth, storage, and on Powabase also ai) to the platform. Note which extensions you use. List every Edge Function and what it does, and every pg_cron job and its schedule, because each gets a new home. Write down your auth setup: OAuth providers, redirect URLs, SMTP settings, and email templates. Count your storage buckets and their size. Find every place a connection string lives, including ORMs, scripts, CI, and BI tools. Then pick a cutover plan: a short write freeze with a final dump, or a staged move where you migrate a copy first, test it, and repeat the dump on cutover day.

• Your own schemas and their size
• Extensions in use
• Edge Functions and what triggers each one
• pg_cron jobs and their schedules
• Auth providers, redirect URLs, SMTP, and email templates
• Storage buckets, sizes, and storage policies
• Connection strings in apps, ORMs, jobs, and BI tools
• GraphQL clients that call /graphql/v1

How do you move the database?

Use standard Postgres tools. Dump only the schemas you own with pg_dump, for example pg_dump --schema=public --no-owner --no-privileges, or use the Supabase CLI's supabase db dump, which Supabase documents for exporting roles, schema, and data as separate files. Then restore into Powabase in a single transaction. Powabase's database URL, postgresql://<ref>:<password>@db.p.powabase.ai:5432/<ref>, goes through PgBouncer in transaction mode, and a single transaction keeps the whole restore on one connection and makes it all-or-nothing. For a plain SQL dump, run psql --single-transaction -v ON_ERROR_STOP=1 -f schema.sql -f data.sql against that URL. For a custom-format dump, use pg_restore --single-transaction. Restore into a test project first and run your app against it. Check the URL shape closely, because the username and database name are both your project ref, and the port is 5432. ORM settings carry over from Supabase's pooler mode, such as ?pgbouncer=true&connection_limit=1 for Prisma and prepare: false for postgres.js. If your tables reference auth.users, bring users across before loading those rows.

How do you move auth users and stored files?

Treat users and files as their own steps, because they live in schemas the platform manages rather than in your dump. For users, export the list from Supabase, for example with the admin API's listUsers, and create each one in your Powabase project through GoTrue's admin endpoints at /auth/v1/admin/users, the same paths Supabase uses. Your own tables usually reference user IDs, so create users before loading those rows, and check that IDs line up. Decide how each user signs in the first time on the new project: a password reset email or a magic link works for everyone, and OAuth users sign in again once you add the new redirect URL at each provider. Configure SMTP and email templates before you invite anyone. For files, create the same buckets in Powabase Storage, copy each object by downloading it from Supabase Storage and uploading it to Powabase with the same path, then recreate your policies on storage.objects. Supabase's own backup-and-restore guide includes a small supabase-js script that copies objects between projects, and because both sides speak the same Storage API, the same approach works here.

Where do Edge Functions and pg_cron jobs go?

Each one maps to a clear home on Powabase, and many get simpler along the way. Logic that ran when a row changed moves to database webhooks, which call an HTTP endpoint from a Postgres trigger. Public HTTP endpoints move to the serverless host you already use, such as Vercel, Cloudflare Workers, or AWS Lambda, and call Powabase from there. Scheduled jobs and background work become workflows: a code block holds the logic in Python or JavaScript, and a schedule trigger runs it by cron expression or interval, which covers what pg_cron did, whether that was a nightly cleanup or a weekly report. Edge Functions that called a model API to answer questions, embed text, or run a tool loop gain the most. They become Powabase agents and knowledge bases, with retrieval, tools, sessions, and streaming built in, so the glue code goes away. GraphQL needs one small change. It is served through PostgREST at /rest/v1/rpc/graphql instead of /graphql/v1, with the same queries. For how agents and workflows fit together, see AI workflow automation.

• Row-change triggers: database webhooks
• Public HTTP endpoints: your serverless host, calling Powabase
• Scheduled jobs and background work: workflows with a code block and a cron or interval trigger
• Model calls, embeddings, and tool loops: Powabase agents and knowledge bases
• GraphQL: POST /rest/v1/rpc/graphql

Can you keep Supabase and add Powabase for RAG and agents?

Yes, and for many teams it's the best first step. Keep your app, users, and data on Supabase, and create a Powabase project for the AI layer. Upload documents to a knowledge base, where Powabase extracts, chunks, embeds, and indexes them. Define agents with tools and the knowledge bases they can search, and workflows for the automations around them. Your backend then calls Powabase's REST API for search and agent runs, and streams results back to your users. Keep the Powabase service key on your server, never in the browser. Your server already knows who the user is from Supabase auth, so it passes the right scope to each call, such as the source_ids that user may search. RAG with Row Level Security shows that pattern. You get managed RAG and agents without touching a working app, and you can move the rest of the backend later, or never. If you built RAG yourself on pgvector, you can also compare that pipeline with a knowledge base side by side before switching, as described in what a vector database is.

Supabase features and where they live on Powabase

• Postgres with RLS

  Powabase:

  Postgres instance per project with RLS

  Migration step:

  pg_dump your schemas; restore in one transaction

• PostgREST API

  Powabase:

  Same PostgREST

  Migration step:

  Change the project URL and keys

• Auth (GoTrue)

  Powabase:

  Same GoTrue, same /auth/v1 paths

  Migration step:

  Recreate users with the admin API; update OAuth redirect URLs and SMTP

• Storage

  Powabase:

  Same Storage API

  Migration step:

  Recreate buckets and policies; copy objects

• Realtime

  Powabase:

  Same Realtime channels

  Migration step:

  Same client code with the new URL and key

• GraphQL at /graphql/v1

  Powabase:

  pg_graphql at /rest/v1/rpc/graphql

  Migration step:

  Change the endpoint path

• Edge Functions

  Powabase:

  Database webhooks, workflows, agents, or your serverless host

  Migration step:

  Move each function by what it does

• pg_cron

  Powabase:

  Workflows with cron or interval triggers

  Migration step:

  Recreate each job as a scheduled workflow

• pgvector tables you built

  Powabase:

  pgvector installed, plus managed knowledge bases

  Migration step:

  Keep the tables, or upload documents to a knowledge base

• Pooler connection string

  Powabase:

  PgBouncer, transaction mode, port 5432

  Migration step:

  Update URLs; keep your pooler-mode ORM flags

Related reading

• Backend & Comparisons

  Best Backend as a Service 2026: Firebase vs Supabase & More

  The best backend as a service compared: Firebase, Supabase, Neon, Appwrite, and Powabase on pricing, features, AI, and lock-in, plus which to pick.

  September 17, 2026
• Backend & Comparisons

  Unified BaaS vs. Compose-Your-Own Stack: Head-to-Head

  Unified BaaS vs compose-your-own stack: which wins for your project? We compare cost, flexibility, and speed so you can choose with confidence.

  July 15, 2026
• RAG & Retrieval

  Multi-Tenant RAG Tenant Isolation

  Master multi-tenant RAG tenant isolation with proven strategies to keep data secure, prevent leakage, and scale confidently across all your customers.

  September 2, 2026