If you are weighing Convex vs Firebase for a CRM you want to own, you are probably not a backend engineer, because a backend engineer would have already picked and moved on. I am not one either. I had to choose a backend for a real thing that real clients would touch, and then live with it. So this is that take, not a spec sheet.
What you are actually choosing between
Firebase is the one everybody has heard of. It is Google's, it has been around forever, it has a huge community, and if you get stuck at 2am there is a Stack Overflow answer for your exact problem. That maturity is real and it counts for a lot when you are learning.
The catch is that Firebase's data model makes you think in a particular way that gets awkward for CRM-shaped work. A CRM is full of related things, contacts linked to deals linked to companies linked to activities, and that relational, everything-connects-to-everything shape is not where a document store feels its best. You end up writing more glue than you expected.
Convex is the newer one, and it is built around TypeScript and reactive queries. In plain terms, you write your backend logic in the same language as the rest of the app, your data updates flow to the screen automatically, and it does not fight you when your data has relationships. For someone building with an AI coding tool, that consistency matters more than it sounds, because the AI writes better code when the whole stack speaks one language.
Why the language thing mattered so much for me
Here is the part that decided it, and its very much a non-developer reason.
When I describe what I want to my coding tool and the frontend, the backend, and the database all live in the same TypeScript world, the AI keeps its footing. It is not translating between a JavaScript app and a separate database dialect and a third thing for server functions. Fewer seams means fewer places for me, the guy who does not actually know what he is doing, to get lost. With Convex the whole thing felt like one system instead of three services I was duct-taping together.
I am sure a real engineer could make either one sing. I am not a real engineer, and I needed the option that let me stay productive without one.
Join the Seedly owners community.
Owners trade setups, share add-ons, and swap playbooks. See what people are building before you commit.
What a real CRM on Convex actually looks like
Rather than talk in the abstract, here is the thing I actually shipped, because scale is where these choices stop being theoretical.
The CRM I sell runs on 201 tables. It carries 608 indexes and 13 full text search indexes, and roughly 2,700 backend functions across queries, mutations and actions. That is not a toy app that proves a point in a blog post. It is contacts, deals, pipelines, calendars, invoices, telephony, forms, workflows and multi-tenant sub-accounts, all leaning on the same backend.
Two things about that shape decided it for me.
The first is relationships. A contact belongs to a sub-account, has deals, has activities, has calls, has invoices, and sits in pipelines. In a document store you either denormalise and then own the problem of keeping copies in sync, or you fan out reads and stitch the result together in your app. Neither is fatal. Both are work you keep doing forever, on every new feature. Six hundred indexes exist because that relational shape is the whole product.
The second is that mutations are transactional. When a deal moves stage, that writes the deal, logs an activity, and can fire an automation. Those either all happen or none of them do. On a CRM that is not a nice-to-have. Half-applied writes are the bug where a client swears they moved the deal and the history says otherwise, and you cannot reproduce it.
Where the auth model actually bites
This is the difference nobody mentions until they are three months in.
Firestore puts your access rules in a separate rules language that lives outside your application code. It works, and plenty of large products run on it. But it is a second place where permissions are defined, in a syntax that is not the one the rest of your app is written in, and it gets checked at a different layer than your business logic.
With Convex, a permission check is TypeScript sitting at the top of the same function that does the work. For a multi-tenant CRM where every single read has to be scoped to the right sub-account, having that check in the same file as the query is the reason I can actually reason about it. That codebase carries over 1,400 automated tests specifically for access control and role permissions, across more than a hundred files, and writing those would have been meaningfully harder against rules in another language.
To be fair to Firebase, "rules live outside your code" is also a legitimate design. It means a client bug cannot bypass them. It is a real trade, not a flaw.
The honest knocks on each
Firebase's downside for CRM work is the data-shape friction I mentioned, plus a second definition of your permissions in a language you use nowhere else, plus being deep in Google's ecosystem, which is fine until it is not. It is mature, and mature also means some of its patterns are older than the problems I was solving.
Convex is younger. The community is smaller, there are fewer blog posts for your exact error, and you are earlier on the curve. It is also a managed platform, so you are trusting a smaller company with the thing your product runs on. I am not going to pretend that is nothing. It is the single strongest argument for Firebase and you should weigh it honestly.
| Convex | Firebase | |
|---|---|---|
| Backend language | TypeScript, same as the app | JavaScript app, separate rules language |
| Data shape | Relational-friendly | Document store, denormalise or fan out |
| Permissions | In the same function as the logic | In a separate rules layer |
| Write guarantees | Mutations are transactional | Transactions available, more manual |
| Community depth | Smaller, newer | Enormous, years of answers |
| Vendor | Smaller company |
Neither one is a mistake. They are different bets, and the table above is the bet, not a scorecard.
So which one do you pick
If you are a non-developer building a CRM you intend to own, I landed on Convex because the single-language, relationship-friendly, reactive setup kept me and my AI tools moving instead of stuck. The CRM I ended up packaging runs on it for exactly these reasons. If you want the deepest bench of existing help while you learn, Firebase is the safer familiar choice.
Either way, the backend is the part you should not be hand-building from zero. I explain why in why forking beats building from scratch, and the reality of building this way is in how I built my own CRM with AI.
Common questions about Convex vs Firebase
Pick the one that keeps you moving.
