Rebase
vs
Directus

Rebase vs Directus

Both read a database you already have rather than owning one, which makes them closer in intent than anything else on this list. They part on two things: where the data model lives — a Directus project configures it in its own tables, a Rebase project in TypeScript you commit — and where permissions are enforced.

Schema management

Code, or database state

Where it hurts

Directus keeps the data model and the interface configuration in its own tables (directus_collections, directus_fields). It ships schema snapshot and schema apply to move that between environments, so this is a workflow rather than a gap. The difference is what the reviewer sees: a Directus snapshot is a generated YAML file describing the model, and a Rebase collection is the TypeScript that produces it — the thing you edited is the thing in the diff.

What Rebase does instead

Rebase takes a schema-as-code approach. Every collection and field is defined in a standard TypeScript file.

  • Even when you add a field in Rebase Studio, the engine uses AST manipulation to write the change into your TypeScript.
  • Changes are committed to Git.
  • A deployment is a git pull and a migration, so environments agree.
Extensibility

A React framework, or a Vue engine

Where it hurts

Directus is an API engine built on Vue.js. Custom dashboards, specialised inputs and unique data views mean adopting Vue workflows and Directus's own extension patterns.

What Rebase does instead

Rebase is built natively on React.

  • Custom fields, whole new pages and bespoke dashboard widgets are ordinary React components, so the ecosystem you already use applies.
  • Use the React components you already have — MUI, Tailwind, Recharts — without a wrapper.
  • The backend is a standard Hono app. A custom route is app.get().
Security & permissions

Native RLS, or the application layer

Where it hurts

Directus enforces permissions in its own application layer rather than in Postgres row-level security. A service that queries the database directly meets none of them.

What Rebase does instead

Rebase compiles the same rules to native Postgres row-level security, and gives you a visual editor over them.

  • Rules are compiled to Postgres row-level security, so they hold regardless of where the query originated — including a psql session that never touched the API.
  • The visual editor makes a policy readable, and reports drift against the database.
  • The security context stays yours, in your repository.

Do not switch

When to stay on Directus

When you need a mature content-management experience today. Directus has years of work in its editorial interface, a larger marketplace, and a broader set of database engines behind it — Rebase is PostgreSQL only, deliberately, because the row-level-security story depends on it. If your team is primarily editors managing content, Directus is the more finished product for that job.

Questions

Rebase and Directus, answered

Can Rebase run on a database Directus already manages?

Yes. Rebase points at an existing PostgreSQL database and reads the tables it finds, so a Directus-managed schema is a valid starting point. Directus's own bookkeeping tables stay where they are and are simply not modelled as collections — you describe the tables you care about and leave the rest alone.

Who owns the schema?

You do, and this is the central difference. In Directus content types are created through its interface, in its migration format, in tables it manages. In Rebase the schema is TypeScript in your repository; Rebase generates the Postgres tables from it and never asks for a shape of its own. Point it at a database that predates it and it works.

Where is access control enforced?

In Postgres. Rebase compiles a collection's access rules into real row-level security policies, so a query that reaches the database any other way — psql, a report, another service — is still governed by them. Directus enforces permissions in its application layer, in front of the database, which is a real and well-built engine but one that stops at the edge of Directus.

When is Directus the better choice?

When you need a mature content-management experience today. Directus has years of work in its editorial interface, a larger marketplace, and a broader set of database engines behind it — Rebase is PostgreSQL only, deliberately, because the row-level-security story depends on it. If your team is primarily editors managing content, Directus is the more finished product for that job.

Does Rebase give me an API as well as an admin panel?

Both, from the same definition. A REST API, a typed SDK, realtime subscriptions and an MCP server for agents are generated from the collections, and the admin panel is a consumer of that same public API under the same policies. There is no private back channel for data, and no second copy of it.

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 Directus.

~pnpm dlx @rebasepro/cli init