Rebase vs Supabase
Both put row-level security in Postgres. The difference is where the policy is written: in Supabase it lives in the database and you keep it in sync with your code by hand; in Rebase it is a field on the collection, compiled to a policy, and the same file generates the API, the typed SDK and the admin panel.
RLS without the footgun
Where it hurts
Both projects put authorization in Postgres row-level security, and Supabase Studio has a policy editor with a generator and templates behind it. The difference is where the policy lives afterwards: in Supabase it is a database object you keep in step with your code by hand, and in Rebase it is a field on the collection that compiles to a policy — so the policy, the API and the panel move together, and drift between code and database is something the editor reports.
What Rebase does instead
Rebase writes the policy where the collection is. Instead of a separate SQL object, you declare the rule in TypeScript and the compiler turns it into a real Postgres policy.
- A visual policy editor that reads the database back and reports drift.
- The rule's context is TypeScript rather than a hand-written JOIN.
- Per-collection, per-field and per-role, in the file the collection lives in.
Self-hosting, symmetrically
Where it hurts
Self-hosting Supabase is a supported path with a published Docker Compose file, and plenty of teams run it. What you are taking on is several services in several languages — PostgREST in Haskell, Auth in Go, Realtime in Elixir, Edge Functions on Deno — each with its own release cadence. Rebase is one Node process and a Postgres, which is a smaller thing to keep upgraded, not a categorically different one.
What Rebase does instead
Rebase is one Node.js backend on standard Hono and Drizzle ORM.
- One service to deploy: Docker, Railway, Fly, or bare metal.
- TypeScript throughout — the language your team already reads.
- No opaque binaries between you and the database.
Schema as code
Where it hurts
With Supabase, the database is the state. Local, staging and production drift apart unless somebody keeps them in step, and version-controlling RPCs, triggers and RLS as raw SQL files takes discipline nobody has on a Friday.
What Rebase does instead
In Rebase the schema definition is a standalone TypeScript file — config/collections/products.ts — and Git is the source of truth.
- Rebase Studio uses AST manipulation to inject fields into your code safely.
- Drizzle migrations are generated and applied from the same definition.
- The code is the source of truth, so environments agree by construction.
Do not switch
When to stay on Supabase
When you want the largest ecosystem in this category, the most third-party tutorials, or edge functions running at the CDN. Supabase is the more mature product with a much bigger community, and if nobody outside your engineering team will ever open the back office, most of what Rebase adds is weight you will not use.
Rebase and Supabase, answered
Can I use Rebase with my existing Supabase database?
Yes. Rebase connects to any PostgreSQL database, including the one behind a Supabase project, and it reads the tables that are already there rather than insisting on its own shape. What does not travel is the part of Supabase that is not Postgres: their auth schema, edge functions and storage buckets are their implementations, so those you would be replacing rather than importing.
If both are Postgres with row-level security, what is actually different?
Where the policies come from. On Supabase you write RLS as SQL in a dashboard, and a policy that silently returns zero rows is a debugging session with no stack trace. In Rebase the policy is part of the collection definition in TypeScript and is compiled to a real Postgres policy when you migrate. The enforcement is identical — it is Postgres in both cases — but the rule lives in your repository, goes through code review, and shows up in a diff.
Isn't the Supabase dashboard already an admin panel?
It is a table editor, which is a different product. It is built for the developer: raw rows, foreign-key UUIDs, no workflow, no roles beyond database roles. Rebase generates an interface for the people who run the business — forms, media, permissions, kanban boards, and your own React components wherever the generated defaults are wrong — out of the same collection definitions that produced the API.
When is Supabase the better choice?
When you want the largest ecosystem in this category, the most third-party tutorials, or edge functions running at the CDN. Supabase is the more mature product with a much bigger community, and if nobody outside your engineering team will ever open the back office, most of what Rebase adds is weight you will not use.
How much of a rewrite is moving an app from Supabase to Rebase?
The database is the part that does not move — it is Postgres on both sides. What changes is the client: Supabase's JS client and Rebase's typed SDK are different APIs, so calls have to be rewritten, and any policy you wrote in the dashboard has to be expressed as a collection's access rules. Realistically it is a client-layer migration, not a data migration.
Do I have to self-host Rebase?
No. Self-host it and you own the data, the code and the machine it runs on — that is the default and it is fully supported. Or deploy the same project to Rebase Cloud, which is live with real tenants today and opening in batches while it is in private beta, priced per resource rather than per seat. Your code is identical either way; hosting is a deployment target, not a fork.
Don't take our word for it.
The comparison that matters is the one you run. Point Rebase at a Postgres database you already have and see how it holds up next to Supabase.