CrescoDB vs Firebase
Firebase is the fastest way to get a mobile app talking to a database, and it has been for a decade. The two things people come looking for an alternative over are the same two every time: a bill that scales with reads rather than value, and a data model that is hard to leave. Here is how CrescoDB answers both — and where Firebase is still clearly better.
The quick answer
\nSkip to the bottom line — then dig into the workflow below.
\nChoose CrescoDB if you…
\n- \n
- want SQL — tables, joins, constraints — not a document store you query sideways \n
- want a cost you can predict from your server, not your traffic \n
- want to be able to leave:
cresco ejecthands you every row as plain SQL \n - are building a web app, API or internal tool more than a mobile app \n
- want the backend to be code in your repo you can read in a diff \n
Choose Firebase if you…
\n- \n
- are building a mobile app — the iOS, Android and Flutter SDKs are still unmatched \n
- need offline-first sync that just works when the phone loses signal \n
- want push notifications, Crashlytics and analytics from the same vendor \n
- expect Google-scale traffic and want someone else to hold that pager \n
- have a tiny app that fits inside the free tier and always will \n
Side by side
\nOnly what each does today.
\n| Capability | CrescoDB | Firebase |
|---|---|---|
| Data model | SQL — SQLite, PostgreSQL or MySQL | NoSQL document store (Firestore / RTDB) |
| Joins and constraints | ✓ real foreign keys, real SQL | ✕ denormalise and fan out |
| Where it runs | Your machine, then a server you own | Google's infrastructure only |
| Self-hosting | ✓ | ✕ not available |
| How you're billed | Flat — your plan plus your own server | Per read, write, delete and GB stored |
| Cost at 10× the traffic | Same server, or a bigger one you choose | Roughly 10× the bill |
| Getting your data out | ✓ cresco eject → plain SQL | Export exists — but the schema is Firestore-shaped |
| Backend code you own and edit | ✓ real files in your repo | ✕ you call their SDK |
| Mobile SDKs | ✕ REST over HTTP from any language | ✓ first-class iOS/Android/Flutter |
| Offline sync | ✕ | ✓ genuinely excellent |
| Push notifications | ✕ | ✓ FCM |
| Auth + roles | ✓ per-table RBAC | ✓ Firebase Auth + security rules |
| Realtime | ✓ (SSE) | ✓ (websockets, deeply integrated) |
| File storage | ✓ | ✓ Cloud Storage |
| Works with no account | ✓ npx crescodb init | ✕ Google account and project required |
| Maturity | 1.0, small team | ✓ a decade, enormous |
What the bill actually looks like
\nThis is the part that sends people looking. Take a modest app: a feed that loads 30 documents per screen, 5,000 daily active users opening it four times a day. That is about 18 million reads a month.
\nCrescoDB
\n- \n
- A $5–$20 VPS runs the API and the database. \n
- 18 million reads is a query. Postgres does not charge you per row returned. \n
- The number changes when you resize the box, and not before. \n
- Nothing about your data model was chosen to keep a counter down. \n
Firebase
\n- \n
- Firestore bills reads at $0.18 per 100,000 — about $32/month for that feed, before writes, storage or bandwidth. \n
- Every optimisation is now also a cost decision: denormalise, cache, batch, restructure. \n
- Storage is billed at $0.26/GB on top. \n
- The Spark free tier caps Firestore at 50,000 reads a day — this app passes that on day one. \n
The part nobody puts in a feature table
\nFirestore is not just a database you are renting — it is a data model you are adopting.
\nBecause Firestore has no joins, a Firebase codebase gets shaped around that: documents are\n duplicated so a screen can be one read, writes fan out to keep the copies in step, and security\n rules encode relationships the schema cannot. None of that is bad engineering — it is the correct\n way to use Firestore.
\nBut it means "we could migrate later" is rarely true in practice. The export gives you your\n documents; it does not give you the relational schema you never wrote. That is the lock-in, and it\n is structural rather than contractual.
\nCrescoDB's answer is not a promise, it is a command you can run before you have committed\n anything to us: cresco eject writes your schema, every row as plain SQL, the engine\n vendored into the folder, and a Dockerfile that builds from that file rather than from the\n internet. What happens if CrescoDB goes away is a page, not a footnote.
The honest bottom line
\nIf you are building a mobile app — especially one that has to work on a bad train connection — Firebase is still the right answer, and it is not close. Offline sync, the mobile SDKs and push notifications are a decade of work that CrescoDB does not have and is not trying to have.
\nIf you are building a web app, an API or an internal tool, most of what you are paying Firebase for is scale you do not need yet, in exchange for a data model you did not choose and a bill that grows with traffic rather than revenue. CrescoDB gives you SQL, a flat cost, and code in your repo.
\nWe will say the honest thing: CrescoDB is 1.0 and built by a small team. Firebase is not going anywhere. If what you want is a vendor that will outlive your project, that is a real argument and we are not going to pretend otherwise — which is exactly why we made leaving a command.
\nTry CrescoDB in 30 seconds
No account, no cloud project. One command.