Should I use Firebase or build my own database for my app?
The database question comes up early and it rarely has a clean answer. Do you reach for Firebase and get moving quickly, or do you build something custom and retain full control from day one? We have been inside both choices on real products, and the honest answer is that neither is universally right. What matters is understanding what each one actually commits you to, because the architecture you pick in month one tends to shape everything that follows.
The question also matters more than it might seem at the start. According to Security Boulevard, 2023, 77% of mobile app developers consider the database the most critical component of their app. That figure lines up with what we see in practice. Performance issues, security vulnerabilities, scaling bottlenecks and migration nightmares almost always trace back to a database decision made early, under time pressure, without full information.
If your MVP needs real-time data sync across devices, Firebase handles this with very little code. Only build custom websocket or polling logic when you have a specific reason Firebase cannot serve the need.
How we locked down Firebase without an API layer
On the performance coaching app, the most demanding technical challenge was not the real-time sync. It was security. By choosing not to build a traditional API for the MVP, we had no controlled intermediary between the client and the database. Everything had to be governed by Firebase security rules alone, and those rules had to be exact.
In a conventional architecture, the API absorbs a lot of that responsibility. It checks whether the requesting user is allowed to see the data before the query even reaches the database. Without that layer, your Firebase rules carry the full burden. A rule that is too permissive leaves data exposed. A rule that is too restrictive breaks the product. There is no server-side fallback catching mistakes.
What we did on that project was scrutinise every rule carefully, tracing each possible access path through both the mobile app and the web response page. Each audience member could read and write only their own response record. No rule permitted access to another user's data. No rule could be exploited from either client surface. It worked, but it required more deliberate attention than security normally demands when you have an API absorbing the risk. The lesson we took from that project is that removing the API layer is a valid choice for an MVP, and it demands proportionally more care applied to the rules that replace it.
Before shipping a Firebase app without an API layer, trace every access path from both your mobile app and any web surfaces. A rule that looks correct in isolation can create an exposure when two surfaces interact.
Where Firebase starts to fight you: security rules, query limits, and the absence of a controlled intermediary
Firebase security rules work well when your access patterns are simple and predictable. They become difficult when your data relationships are complex, when different users need access to overlapping subsets of the same data, or when your security logic depends on conditions that Firestore rules cannot express natively. Rules are declarative and evaluated against the request and the document, not against arbitrary server-side logic.
Firestore's query model is a separate constraint. You can only query data you have permission to read, which sounds reasonable until you realise it shapes your data structure from the start. Queries that would be simple in SQL, filtering across multiple fields or joining data from different collections, require you to denormalise data, maintain duplicate fields, or add indexes explicitly.
The absence of a controlled intermediary also affects what you can do with data before it reaches the client. On a custom backend, you can transform, filter, aggregate or enrich data in the API layer without the client ever seeing the raw records. Firebase sends the data to the client, and the client handles it. For products where data logic is simple, that is fine. For products where business rules are complex, or where you need to prevent raw data from ever leaving the backend, it is a meaningful limitation.
When performance problems hide in the database layer
On a real-time messaging product we built using Firebase Firestore, performance started degrading in a way that was not immediately obvious. The product included an anonymous messaging feature where users could read messages without the sender being identified. That anonymity requirement needed specific security rules, and those rules were running against every message read.
Our first assumption was that the problem sat in the application code. We reviewed the logic, profiled the app, and looked for inefficiencies in how the client was handling data. The application code was not the issue. After deeper investigation, we traced the slowdown to the database layer itself. The security permission checks were running inefficiently because of how the messages were stored. Adding extra indexes and restructuring the way messages were organised allowed those checks to run far more efficiently, and the performance problem resolved.
That experience changed how we approach performance on Firebase projects. The database structure and the security rules interact in ways that are not always visible at the schema design stage. A structure that looks clean can create expensive permission evaluations at read time. The solution was not a code rewrite. It was a data model rethink, which meant revisiting decisions made much earlier in the build.
| Performance symptom | Common cause in Firebase | Fix |
|---|---|---|
| Slow reads on large collections | Missing or misaligned indexes | Add composite indexes matching your query patterns |
| Security rule evaluation lag | Rules checking across multiple documents per read | Restructure data to reduce cross-document rule checks |
| Client overload on real-time listeners | Listening to collections that are too broad | Narrow listeners to specific documents or subcollections |
What a custom or serverless database architecture actually costs to build and run
The cost of a custom database architecture has two parts: the cost to build it and the cost to run it. Building it takes longer than spinning up Firebase, because you are making decisions Firebase makes for you: which database, which infrastructure, how the API is structured, how authentication works. That initial overhead is real, and for an MVP trying to get to users quickly, it is worth taking seriously.
Running costs depend on what you build. A serverless approach, as we used on the cybersecurity LMS project with AWS Lambda and S3, means you pay for what you use rather than for servers running continuously. At low traffic, that is often cheaper than the equivalent Firebase bill. At high traffic, the comparison shifts and depends on your specific usage patterns.
The cost that is hardest to estimate is migration. If you build on Firebase and later need to move to a custom backend, you are re-architecting the data model, rewriting the API layer, and migrating existing data without disrupting users. Enterprise migration projects average $315,000 according to CIO Dive, though that figure covers large-scale moves rather than typical app backends. The principle holds at any scale: migration is expensive, and the cost compounds if the product has grown before you start.
Model your Firebase usage at three traffic levels, current, 10x current, and 100x current, before committing. Firebase pricing scales with reads, writes, and data transfer, and the numbers can shift considerably as the product grows.
The decisions that are hardest to reverse
Some architectural choices are easy to change later. The database structure is not one of them. Once a product has real users and real data, changing how that data is stored, how it is queried, and how security is enforced requires a migration plan, downtime management, and usually a parallel-running period where old and new structures coexist. That is expensive in time and risk.
The hardest decision to reverse on a Firebase product is the choice to go without an API layer. On the performance coaching app, that was the right call for an MVP. But as a product grows, business logic accumulates. Rules that started simple get complex. Transformations that would be trivial in an API become awkward in client code or require Cloud Functions to replicate the intermediary layer that was removed. What starts as leaner architecture can gradually rebuild the complexity it was designed to avoid, in a less controlled form.
Vendor lock-in is also worth naming directly. Firebase is Google's product, running on Google's infrastructure, with Firebase-specific query patterns, security rule syntax, and SDK behaviour. Moving off it means relearning and rewriting, not just migrating data. The Zapier survey found that 47% of AI users say a key business function would malfunction if their primary vendor went offline. Database lock-in creates a comparable dependency, and it is worth assessing that risk before it becomes a problem.
- Data model structure, hard to restructure once users and data exist
- API layer presence or absence, complex to retrofit later
- Vendor dependency, Firebase patterns do not port cleanly to other platforms
- Security rule architecture, deeply tied to data structure choices
How to assess which choice fits your product right now
The right question is which option fits where your product is right now, and where it is going within the next 12 to 18 months. Firebase fits a specific set of conditions well: you need to move fast, your real-time data requirements are genuine, your access patterns are relatively predictable, and you are not yet certain the product will survive contact with users. At that stage, the speed advantage outweighs the constraints.
A custom or serverless architecture fits a different set: your business logic is complex from the start, your security requirements demand a controlled intermediary, you have strong reasons to avoid vendor lock-in, or you have already validated the product and know it needs to scale. The cybersecurity LMS is a good example. The client's needs were specific and the product was going into a context where the architecture needed to be defensible, so the serverless custom build was the right call from the beginning.
| Condition | Firebase | Custom / Serverless |
|---|---|---|
| Need to ship an MVP quickly | Strong fit | Slower start |
| Real-time sync is core to the product | Strong fit | Requires extra engineering |
| Complex business logic or data transformations | Awkward without API layer | Strong fit |
| Strict data residency or compliance needs | Limited control | Strong fit |
| Long-term cost predictability needed | Variable at scale | More predictable |
Run through your core user flows and ask for each one: does this need server-side logic that the client should never see? If the answer is yes for more than two or three flows, you want an API layer from the start.
Conclusion
Firebase is a sound choice for the right product at the right stage. The performance coaching survey app worked because Firebase's real-time capability was central to the product and the MVP timeline did not allow for a full custom build. We made it work securely by being deliberate about every rule. But we also saw on the same project what the absence of an API layer demands: more scrutiny, more precision, and a clear understanding of where the risk sits without a controlled intermediary.
The messaging product taught us something different. Performance problems in a Firebase app do not always come from the application code. Sometimes they come from the data model and the security rules interacting in ways that only become visible under real load. Finding that and fixing it meant going back to decisions made early in the build.
For the cybersecurity LMS, a custom serverless architecture was right from the start. The product needed control that Firebase could not provide, and the modern tooling made the build straightforward. Storing infrastructure as code meant new environments were available in minutes, which changed how we could test and iterate.
Neither path is the obvious one. Both have real costs and real benefits, and those costs show up at different points in the product's life. If you are trying to work out which fits what you are building, let's talk through your product.
Frequently Asked Questions
Firebase is well suited to MVPs because it lets you move quickly without building a full backend infrastructure. The trade-off is that the architecture you choose early tends to shape everything that follows, so it is worth understanding what Firebase commits you to before you begin.
According to Security Boulevard, 77% of mobile app developers consider the database the most critical component of their app. Performance issues, security vulnerabilities, scaling bottlenecks and migration problems almost always trace back to a database decision made early, often under time pressure and without full information.
Yes, real-time data sync across devices is one of Firebase's strongest capabilities and it requires very little code to implement. You should only consider building custom websocket or polling logic when you have a specific reason Firebase cannot serve the need.
It is a valid approach for an MVP, but it places the full security burden on your Firebase security rules rather than on a controlled server-side intermediary. This means every access path must be scrutinised carefully, because a rule that looks correct in isolation can create an exposure when multiple client surfaces interact.
Firebase security rules work well when access patterns are simple and predictable, but they become difficult to manage when data relationships are complex or when different users need access to overlapping subsets of the same data. Rules are declarative and evaluated against the request and the document, not against arbitrary server-side logic, which limits what conditions they can express.
Firestore only allows you to query data you have permission to read, which shapes your data structure from the very beginning. Queries that would be straightforward in SQL can become complicated or even impossible without restructuring your data to fit Firestore's model.
A custom database becomes more appropriate when your security logic is complex, when you need fine-grained control over queries across multiple fields, or when your data relationships do not fit neatly into Firestore's document model. If you anticipate these needs early, investing in a custom solution from the start can save significant rework later.
You should trace every possible access path through both your mobile app and any web surfaces before you ship. This is essential because a rule that appears correct when reviewed in isolation can create a security exposure when two different client surfaces interact with the same data.