Rebase vs Hasura
Hasura generates a GraphQL API and a console for building it. Rebase generates REST, a typed TypeScript SDK and an admin panel your operations team can work in, from the same collection definition — and its permissions compile to Postgres policies rather than to metadata the engine applies.
An API, and then what
Where it hurts
Hasura focuses on the API layer. It generates GraphQL quickly and gives your non-technical teammates nothing — the back office is still yours to build, or to rent from an internal-tool builder.
What Rebase does instead
Rebase generates the API layer and the application layer from the same file.
- REST endpoints and a typed SDK, generated from your Postgres schema.
- Rebase also generates Rebase CMS — a React admin panel with editing, auditing and dashboards — from the same definition.
Where the business logic runs
Where it hurts
Running business logic in Hasura — charging a Stripe customer when a row is inserted — means Actions or Event Triggers, which means standing up and maintaining a separate server to receive the webhooks.
What Rebase does instead
Rebase is one Node.js backend.
- Your business logic runs in the same process as the generated endpoints.
- No network hop for an internal trigger, and no webhook configuration to keep in sync.
- One TypeScript repository, one deployment.
Do not switch
When to stay on Hasura
When GraphQL is the product decision, when you need to federate several data sources behind one graph, or when your clients are already generating code from a GraphQL schema. Those are Hasura's home ground.
Rebase and Hasura, answered
REST or GraphQL?
Rebase generates a REST API and a typed TypeScript SDK; Hasura generates GraphQL. If GraphQL is a requirement — a federated graph, clients that depend on it, an existing schema stitched across services — Hasura is built for that and Rebase is not. If you mainly wanted a good API over Postgres without writing one, the typed SDK gets you there with less machinery in between.
Can Rebase run on a database Hasura already serves?
Yes. Both point at an existing PostgreSQL database rather than owning it, so the same schema can back both while you evaluate. Hasura's metadata lives in its own schema and is left alone.
How do permissions compare?
Hasura's permission system is defined in its metadata and applied by the engine as it builds each query — powerful, and thoroughly designed. Rebase compiles access rules to PostgreSQL row-level security, so enforcement happens inside the database and survives any client, including ones that never go through Rebase. The trade-off is expressiveness against reach.
What does Rebase add that Hasura does not?
An admin panel your non-technical colleagues can use, generated from the same definitions as the API. Hasura's console is a developer tool for building and inspecting the graph; it is not a back office, and it is not meant to be. If you have been planning to build an internal UI on top of Hasura, that is the piece Rebase brings.
When is Hasura the better choice?
When GraphQL is the product decision, when you need to federate several data sources behind one graph, or when your clients are already generating code from a GraphQL schema. Those are Hasura's home ground.
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 Hasura.