Skip to main content
Powabase is a Supabase fork plus an agentic AI surface. If you’ve built on Supabase, most of your existing knowledge transfers — PostgREST is identical, GoTrue is the same version line, Storage is bit-compatible, RLS works the same way. This guide covers what’s different, with concrete rewriting notes for the patterns that change. For the BaaS surface in general, see the relevant per-area pages. For the agentic API (the Powabase-specific addition), see the Auth & Connection guide and follow the links into the AI surface from there.

​
What’s identical

The following work unchanged from Supabase. You can copy a Supabase guide verbatim and substitute the URLs.
  • PostgREST. Same version line (v14.1 on Powabase), same filter operators, same embed syntax, same Prefer headers. See PostgREST reference and PostgREST advanced.
  • GoTrue / Auth. v2.184.0 — same endpoints (/auth/v1/*), same JWT shape, same OAuth provider list. See Auth model.
  • Storage. v1.33.0 — same bucket/object model, same TUS upload protocol, same signed URL flow. See Storage model.
  • RLS patterns. auth.uid(), auth.jwt(), auth.role() work identically. Policy syntax is plain Postgres. See RLS Model.
  • Realtime. v2.65.3 — three channels (Broadcast, Presence, Postgres Changes), same Phoenix Channels frame format. See Realtime model.
  • pg_graphql. Available via POST /rest/v1/rpc/graphql (not a dedicated /graphql/v1 route — see below).
If you’re porting a Supabase project, the realistic move is “copy your code, change the URL, fix the handful of differences below.” Most teams need a day to ship.

​
What’s different

​
Database URL: username and database are both <ref>

Supabase URL: 
postgresql://postgres.<ref>:<password>@aws-0-us-east-1.pooler.supabase.com:6543/postgres
Powabase URL: 
postgresql://<ref>:<password>@db.p.powabase.ai:5432/<ref>
Three differences:
  1. Username is <ref>, not postgres. Powabase’s PgBouncer routes by database name; the connection pool uses <ref> as the user.
  2. Database is <ref>, not postgres. Same reason.
  3. Port is 5432, not 6543. Powabase has one pooler endpoint; no separate session-mode port.
ORM connection-string flags carry over: ?pgbouncer=true&connection_limit=1 for Prisma, ?prepare=false for Drizzle’s postgres.js, prepare_threshold=None for psycopg, etc. Same flags as Supabase pooler mode. See Connection pooling.

​
Pooler is PgBouncer, not Supavisor

Supabase recently migrated to Supavisor. Powabase still uses PgBouncer. Practically:
  • Transaction mode only. No session-mode endpoint on a different port. Anything that needs session state must run inside an explicit transaction.
  • No direct (non-pooled) URL. Supavisor offers both a direct connection and pooler-fronted; Powabase only offers the PgBouncer URL externally. Direct Postgres is in-cluster only.
The per-driver workarounds are the same. The choice of “transaction vs session mode” doesn’t apply — you’re always transaction mode.

​
No /graphql/v1 route

pg_graphql is preloaded and the graphql_public schema is in PostgREST’s exposed schemas. But there’s no dedicated /graphql/v1/* Kong route — call GraphQL through PostgREST RPC: 
POST /rest/v1/rpc/graphql
{
  "query": "{ usersCollection(first: 10) { edges { node { id email } } } }",
  "variables": {}
}
If your code targeted /graphql/v1, point it at /rest/v1/rpc/graphql and the rest works the same.

​
No Edge Functions

Supabase’s Deno-based Edge Functions are not deployed on Powabase. There’s no /functions/v1/* route, no supabase functions deploy workflow. What to use instead, depending on what you used Edge Functions for:
  • Auth webhooks / row triggers — use Database webhooks (the supabase_functions.http_request() trigger pattern).
  • Public HTTP endpoints — host them yourself on whatever serverless platform (Vercel, Cloudflare Workers, Lambda) and call Powabase from there.
  • Background jobs — use a Workflow with the code block type for the logic and a scheduled trigger.
  • The agentic AI use case — the entire reason Powabase exists. Use Agents directly instead of building Edge Functions that call the OpenAI API.

​
ai schema is new

The most novel thing about Powabase is the ai schema. It’s where the AI surface’s state lives: sources, knowledge_bases, agents, workflows, etc. You can query it via PostgREST under RLS (35+ tables exposed) — see Querying the ai schema. If you’re porting a Supabase project that built RAG yourself with pgvector tables in public, you have two options:
  1. Keep your existing tables. vector is still preloaded; nothing breaks. See User-managed pgvector.
  2. Migrate to the typed surface. Move documents to /api/sources, create a KB, and switch retrieval to /api/knowledge-bases/{id}/search. The platform handles chunking, embedding, indexing, and reranking. Trade-off: less control, more reliability + features (multiple retrieval methods, reranker catalog, etc.).
For new projects, the typed surface is the right default. For migrations, “keep what works” is reasonable until you have a reason to change.

​
pg_cron not available

pg_cron is not enabled on Powabase. If you used it for scheduled jobs:
  • Periodic table maintenance / cleanup. Run as a workflow with a cron trigger.
  • Periodic email reports. Same — workflow with cron trigger, calling a general_api block to your email service.
  • Per-second polling. Probably the wrong shape. Switch to event-driven (Realtime postgres_changes or DB webhooks).

​
pg_jsonschema not available

Use CHECK constraints for simple validation, or validate at the application layer.

​
Free-tier billing model differs

Supabase’s free tier has soft limits (project pauses after inactivity, weekly egress quotas). Powabase’s free tier has a hard 402 on credit exhaustion (see Billing model). Different shape — same posture of “free for prototyping, pay for production.” The 402 response includes renews_at (first of next UTC month). Surface that to your users so they know when their credits refresh.

​
Auth proxy paths differ

Supabase’s admin auth lives at /auth/v1/admin/*. Powabase has those endpoints too (same paths), plus the control-plane proxy at /api/platform/auth/<ref>/* which proxies into the per-project GoTrue. The proxy is for Studio-internal admin operations; you almost certainly want the direct per-project endpoints. See Auth reference.

​
What you have that Supabase doesn’t

  • Agentic API — Agents (/api/agents), Knowledge Bases (/api/knowledge-bases), Sources (/api/sources), Workflows (/api/workflows), Orchestrations (/api/orchestrations). The differentiating feature.
  • Five RAG indexing strategies — chunk_embed, full_document, page_index, graph_index, doc2json. Each is an opinionated indexing pipeline.
  • Four retrieval methods — vector_search, full_text (BM25), hybrid, tree_search (for page_index strategy).
  • Reranker catalog — Cohere, Jina, Voyage, ZeroEntropy options on the KB search.
  • realtime.send() and realtime.broadcast_changes() — SQL functions for emitting broadcast messages from triggers without going through pg_net.
See Platform overview for the full surface.

​
What you should not migrate

ai.*, auth.*, storage.*. The platform manages those schemas; modifying them risks breaking the corresponding services. Connect as supabase_admin only to migrate your own public.* and extensions.*. See Migrations.

​
Concrete porting checklist

  1. Update the Database URL — new format, new pooler hostname.
  2. Strip pg_cron / supabase functions references — port to workflows or self-hosted.
  3. Repoint GraphQL from /graphql/v1 to /rest/v1/rpc/graphql.
  4. Audit RLS on ai.* if your app exposes the AI surface to clients — defaults are permissive for authenticated.
  5. Replace billing assumptions — soft limits → hard 402 with credit refill.
  6. Decide on RAG path — keep your pgvector tables, or migrate to the typed Sources + KB surface.
  7. Move scheduled jobs to workflows — cron-triggered workflows replace pg_cron.
For most production Supabase projects, this is half a day to a day of focused work.

​
Next steps

Platform overview

The full Powabase surface — what’s worth knowing about beyond the BaaS layer.

Glossary

Terminology that overlaps confusingly.

Common pitfalls

The footgun list — most are Powabase-specific things Supabase users hit.

Auth & Connection

The Connect modal — your starting point in the Studio.