Rebase vs Appwrite
Both give you auth, a database, storage, functions and realtime behind one API. The difference is the database. Appwrite's belongs to the platform: you reach it through Appwrite's API, and its native SQL option comes without the platform attached. Rebase generates the API, the typed SDK and an admin panel on a Postgres you own, and enforces access in the database itself.
The platform or SQL — or both
Where it hurts
Appwrite 2.0 runs TablesDB on PostgreSQL by default, with relationship columns and transactions. But the database belongs to Appwrite: it creates and owns the schema, you reach the data through its query API, REST or GraphQL rather than SQL, and there is no documented way to point it at the tables of a database you already have. Appwrite Cloud now also sells native PostgreSQL with full SQL — which its own docs describe as having no Appwrite layer in between. You choose between the platform and the database.
What Rebase does instead
Rebase generates the platform on top of a Postgres you own, so there is nothing to choose between.
- Point it at an existing database and it infers collections from the tables already there.
- The generated API and psql read the same tables, so BI tools and ETL jobs keep working.
- When the generated API is not enough, write the join or the view in SQL.
Permissions in the server, or in the database
Where it hurts
Appwrite's permission model is a good one: read, create, update and delete on tables and rows, for any visitor, signed-in users, a user, a team, a team role or a label, closed by default and honoured by realtime. It is enforced by Appwrite's server, though, so it protects the requests that pass through that server. A server API key with the right scopes skips it entirely, and native PostgreSQL on Cloud has none of it.
What Rebase does instead
Rebase compiles access rules to Postgres row-level security, so they hold whichever way a query arrives.
- Rules are declared on the collection in TypeScript and land in the database as real policies.
- A table without RLS is not served at all, and an API key never bypasses a policy.
- Realtime subscriptions are delivered under the same policies as every other read.
A developer console, or an admin panel for your team
Where it hurts
The Appwrite Console is a capable developer tool: a table editor, CSV import and export, logs, and since 2.0 an API explorer and a terminal for the CLI. It is not built for the people who run the business. There are no custom forms or workflow views, nothing a support agent or a content editor would recognise as their tool — so that panel is still a project you build yourself on the SDK.
What Rebase does instead
Rebase generates Rebase CMS, a React admin panel, from the same collection definition as the API.
- Spreadsheet-style tables, forms and kanban boards, generated from the schema.
- Safe to hand to non-technical teammates, because the policies are in the database.
- Replace any part of it with your own React components.
Do not switch
When to stay on Appwrite
When your app is Flutter, Swift or Kotlin: Appwrite has official client SDKs for all three, and Rebase's typed SDK is TypeScript only. When you want push notifications and SMS, dozens of OAuth providers, or functions in Python, Go or Dart from the same platform — Appwrite ships those and Rebase does not. And when nobody outside engineering will open the back office and nothing but your app will ever read the data, a database you cannot reach directly is not a cost you will feel.
Rebase and Appwrite, answered
Can I move an Appwrite project to Rebase?
Yes, but it is a migration rather than a connection change, because Appwrite's database belongs to Appwrite even when it runs on PostgreSQL. The rows come out through its API and go into Postgres tables you define — usually close to one-to-one, since TablesDB is already tables, rows and columns, and relationship columns become foreign keys. Users, storage files and functions are Appwrite's implementations, so those are moved or rewritten rather than connected.
Appwrite runs on PostgreSQL now. What is still different?
Who the database answers to. A self-hosted Appwrite 2.0 defaults to PostgreSQL, but Appwrite creates the schema, checks permissions in its own server, and exposes the data through its query API, REST and GraphQL rather than SQL. Appwrite Cloud's native PostgreSQL gives you SQL, and with it no Appwrite SDKs and no platform permissions. Rebase is both at once: the API, the typed SDK and the admin panel are generated on top of tables you can also open in psql, under the same row-level security.
Does Rebase cover the auth features Appwrite has?
Most of them, with gaps worth naming. Rebase ships email and password, magic links, email one-time codes, anonymous sessions, TOTP multi-factor, scoped API keys and twelve OAuth and OIDC providers — or your own adapter in front of Auth0, Clerk or Firebase Auth. Appwrite has many more OAuth providers, phone and SMS sign-in, and email or SMS as second factors. Neither has built-in SAML for your end users. What Rebase adds is where users live: a table in your own Postgres that policies and queries can join against.
When is Appwrite the better choice?
When your app is Flutter, Swift or Kotlin: Appwrite has official client SDKs for all three, and Rebase's typed SDK is TypeScript only. When you want push notifications and SMS, dozens of OAuth providers, or functions in Python, Go or Dart from the same platform — Appwrite ships those and Rebase does not. And when nobody outside engineering will open the back office and nothing but your app will ever read the data, a database you cannot reach directly is not a cost you will feel.
Does Rebase have functions, storage and messaging like Appwrite?
Functions and storage, yes; messaging only by email. Rebase has TypeScript functions mounted as API routes, cron jobs, background jobs with retries, and file storage on local disk, any S3-compatible service or Google Cloud Storage. It sends transactional email over SMTP, but it has no push notifications or SMS, and its functions are TypeScript only where Appwrite's run in more than a dozen languages.
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 Appwrite.