Compare
Rebase, next to
the tool you already use.
Most of these products are good. They are also solving a different problem than we are. Below: what actually differs, which tool wins in which situation, and the cases where you should not pick Rebase.
Start here
What are you actually shopping for?
Rebase sits across four categories, which is why one-line comparisons never land. Find the row that matches what is open in your other tab.
01
A backend-as-a-service
You want APIs, auth and realtime over a database without writing a server.
How they model it
Postgres or a proprietary store, plus a dashboard built for you — the developer — not for the people who run the business.
How Rebase models it
The same APIs, plus an admin panel your non-technical team lives in, generated from the collections you already wrote.
02
A headless CMS
You want editors to manage content without touching the database.
How they model it
The CMS owns the schema. Your tables are its tables, in its shape, reachable through its API and its permission engine.
How Rebase models it
Your Postgres schema stays yours — including the tables that existed before Rebase. Access control is RLS on those tables, readable by any Postgres client.
03
An internal-tool builder
You want a back office fast and you don't care how it's built.
How they model it
A hosted canvas that connects to your database over a credential you hand it. Screens are drawn by hand, per screen, forever.
How Rebase models it
Screens are generated from the schema, so a new column shows up everywhere at once — and the tool runs on your infrastructure with no outbound connection.
04
A framework admin
You already have a backend and want the batteries-included admin that comes with it.
How they model it
Excellent admin, tied to one language and one ORM. Your React frontend still needs an API you write and maintain by hand.
How Rebase models it
The admin and the typed API come from the same definition, and the API is a first-class product rather than an afterthought.
The real differences
Five questions, not a feature checklist
Everything in this market has tables, forms and an API. These are the five answers that change what your system looks like in two years.
The question
Most of the category
Rebase
Where authorization is enforced
In the application layer, by a permission engine in front of the database. Reach the data another way and the rules are gone.
In Postgres. Every request runs as a restricted role under row-level security, generated from your collection definition.
Who owns the schema
Usually the tool. Content types are created through its UI, in its migration format, in tables it manages.
You do. Point Rebase at a database that already exists; it reads your tables and never demands its own shape.
Who the back office is for
Either the developer (a database dashboard) or the editor (a CMS) — rarely both, and rarely extensible in the framework you already use.
Your team. Roles, media, workflows — and your own React components wherever the generated defaults don't fit.
How many copies of your data exist
Often two: the source database and the tool's own store, kept in step by a connector you have to watch.
One. The panel talks to the same public API as your app, under the same policies. No sync, no mirror, no cache to reconcile.
What happens if you stop using it
Depends how deep the tool went into your schema. If it created the tables, leaving means a migration.
The database keeps working — policies, constraints and data exactly where they were. The panel was a dependency you can delete.
Row one, in practice
Policies are a file, not a setting
The first row of that table is the one that matters most, so here it is as a screen rather than a claim. Access rules live next to the collection that owns them, compile to real Postgres policies, and the editor tells you when the database and the code have drifted apart.
A tool that enforces permissions in its own middleware cannot show you this screen, because the rules are not in the database to be shown.
How the security model worksrebase.uid() = idrebase.uid() = idrebase.uid() = idauth.role() = 'admin'The honest part
Four times you should not pick Rebase
- You are not on Postgres and don't intend to be.The whole security model is Postgres row-level security. On MySQL or Mongo, none of the interesting part applies.
- You want a managed platform with a support contract today.Rebase Cloud has not launched. Right now this is software you run — Docker, Railway, Fly.io or your own metal. If you need someone else on call, a hosted competitor is the right answer this quarter.
- You need a marketing-website CMS.Page builders, visual layout and publishing workflows are what a content platform is for. Rebase manages application data, not landing pages.
- You want to draw every screen by hand.Rebase generates the back office from your schema and lets you replace pieces with your own React. If the point is a bespoke canvas per screen, an internal-tool builder will feel better.
Easier to try than to compare
The live demo is a real Rebase backend with its generated panel on top. No signup.
