Rebase vs Firebase
Firestore is a document store, and joins, constraints and reporting are the things it asks you to design around. Rebase starts from a relational schema you already own — and the console you get is an admin panel your team can work in, not a data browser for developers.
A document store, or a relational one
Where it hurts
Firestore is a document store, so a JOIN is something you design around: denormalise across collections and keep the copies in step with Cloud Functions. Firebase does now offer a relational option — SQL Connect, formerly Data Connect, which puts GraphQL, raw SQL and query subscriptions over a Cloud SQL for PostgreSQL database — but it is a separate product from the Firestore most Firebase apps are built on, and it is Google's Postgres rather than yours.
What Rebase does instead
Rebase runs on a relational PostgreSQL database you own.
- Store a user's name exactly once. Update it once.
- Joins are joins, resolved by the database rather than by a sync script.
- Constraints and foreign keys keep integrity where it belongs.
A console for your data, or an admin panel for your team
Where it hurts
The Firebase Console is a developer tool. If the customer-success team or a content writer needs a dashboard, you build an entire admin panel yourself and wire it to the Firebase SDK.
What Rebase does instead
Rebase generates Rebase CMS, a production-ready React admin panel, from the same collection definition.
- Tables, kanban boards and edit screens, 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.
Google Cloud, or wherever you deploy
Where it hurts
Firestore is proprietary to Google Cloud, and its document model is not a relational one. Moving off it is not an export — it is a remodelling exercise, and the cost is proportional to how much of the shape you denormalised to make Firestore work.
What Rebase does instead
Rebase is MIT-licensed and ships as a Docker image.
- Host on AWS, DigitalOcean, Fly.io, Railway, Hetzner, or your own hardware.
- Underneath it is an ordinary PostgreSQL database, so any BI tool, ETL job or psql session that speaks Postgres already works against it.
Do not switch
When to stay on Firebase
When you are building a mobile app that has to work offline. Firebase's client SDKs and their offline persistence are genuinely excellent and there is no equivalent here. It is also the better answer if you want Google's operational scale without thinking about a database at all — the flip side of owning your Postgres is that you own your Postgres.
Rebase and Firebase, answered
Can I migrate from Firestore to Rebase?
The data can move, but it is a genuine migration rather than a connection change: Firestore is a document store and Rebase is relational, so collections of nested documents have to be modelled as tables and foreign keys. That modelling work is the migration. What you get for it is SQL, joins, transactions and constraints — which is usually the reason people leave in the first place.
Does Rebase have realtime like Firestore?
Yes — realtime subscriptions over WebSocket, driven by changes in Postgres, and delivered under the same row-level security as every other read. That last part is the difference worth knowing: a subscription cannot see rows the subscriber is not allowed to read, because the policy is enforced by the database rather than by the code that set up the listener.
What replaces Firebase Auth?
Rebase ships its own authentication: email and password, magic links, one-time codes, TOTP multi-factor, scoped API keys, and twelve OAuth and OIDC providers including Google, Microsoft Entra ID, Apple and GitHub — or your own adapter in front of Auth0, Clerk, or Firebase Auth itself. The signed-in user's identity is what row-level security policies are written against. The practical difference is that your users live in your own Postgres, in a table you can query and join against, rather than in a separate identity service you reach over an API.
When is Firebase the better choice?
When you are building a mobile app that has to work offline. Firebase's client SDKs and their offline persistence are genuinely excellent and there is no equivalent here. It is also the better answer if you want Google's operational scale without thinking about a database at all — the flip side of owning your Postgres is that you own your Postgres.
Why move to Postgres at all?
Usually because a query got hard. Document stores are pleasant until you need to ask a question that spans three collections, enforce that two writes happen together, or hand an analyst something they can query. Those are one-line problems in SQL and architectural problems in Firestore.
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 Firebase.