Should you use Firebase for your app or website?

My own story

First off, I love Firebase, but I’m not ignorant to what it is and is not. For my current project, which is a startup with a web platform, I started with Firebase for my database, authentication, hosting, backend, and object storage. I have recently made the decision to “graduate” from Firestore to Postgres, and from Firebase Hosting (I tried their new App Hosting service too) to Vercel for my Next JS app. It’s not that Firebase isn’t good, but rather that my needs have changed as I’ve learned more about my project’s requirements. I am still using Firebase for other things such as object storage and authentication. Additionally, if I ever decide to build a mobile app, then I’ll have a good foundation by having Firebase remain in place.

What’s your end goal?

Are you trying to build a billion dollar startup that will rival Facebook and Google or just playing around to build something cool?

If you just want to play around with cool technology, have fun, and build something interesting, than it really doesn’t matter because you’ll have fun no matter which tech stack you use. In this case, I would say identify the parts of the puzzle you want to build yourself and use services to handle the rest for you.

If you’re goal is to build the next unicorn startup I would highly advise using Firebase (or an alternative like Supabase). Why, you might ask - great question! Startups are about moving as quickly as possible in order to reach product market fit (PMF), and once you do so they’re about capitalizing on that fit. This means you should be spending as much of your resources (time & money) on building technology that delivers the value you intend to create, not reinvent the wheel. In other words, let’s say you’re building a revolutionary to-do list app which requires a database of some sort. In this case, you’re in the business of helping people manage they’re daily task list, not managing database infrastructure - there are companies that do that already. What this means for you is that Firebase provides out-of-the-box solutions to common app/web app development problems and since solving those problems (i.e. reinventing the wheel) isn’t what you’re actually in the business of doing you should outsource them to a platform like Firebase since they are actually in the business of solving them.

Also, in the case that you’re building the next big startup unicorn, chances are you’re going to be rewriting a lot of code and moving away from some services as you get bigger, regardless of if you choose to use Firebase or not.

It should also be mentioned that if you’re planning to immediately build enterprise software and have requirements such as handling multi-tenancy, or single-tenancy, then you probably aren’t going to be looking at Firebase… at least not as a blanket solution.

Will Google kill Firebase?

Anytime Firebase comes up, there’s always someone (usually an engineer or a business person who has heard it from an engineer), who says “never use Firebase because Google will kill it soon”. Then they point to some Killed by Google. The short answer to this question is probably not. Here’s my logic for this:

One, Firebase makes Google money. There are a lot of apps using Firebase, some of them quite popular. Firebase is also one of, if not, the biggest players in its space. If you look at the products that Google has killed over the years, they were mostly products that never became dominant players in their respective categories. For example, at the time of writing this, Google has most recently decided to kill off Jamboard, its collaborative digital whiteboard product. Instead of going along with the “Google kills everything” narrative, let’s ask ourselves why - why would Google kill of such a product? Well, according to 6sense, another app called Miro is the biggest player in this product category with an estimated 88.99% market share. This is in contrast to Jamboard, which they estimate to have only 3.30% market share. The question now becomes why shouldn’t Google kill of this product? After-all, for a company like Google to pour millions into something there needs to be a sizable ROI - they likely gave it a shot, realized they couldn’t accomplish what they originally set out to, and decided to move on.

Two, Firebase is likely a part of Google’s GCP strategy. I don’t think I’ve heard anyone talk about this, but Firebase is most ideal for side projects, startups, and maybe medium-sized businesses. On the other hand, raw GCP is more of an AWS competitor. With this context, I think Google is using Firebase as part of its sales funnel to get more customers for GCP. Let’s say you use Firebase for your app. You have a lot of data, but Firestore is able to handle everything in the beginning while you’re figuring things out. Up until now, you’re just a Firebase customer (yes, I realize Firebase is an abstraction over GCP). As your app continues to grow, you come to the conclusion that you’d greatly benefit from both a SQL database and a data warehouse. You could use AWS since they’re a leader in that space, but then you find that GCP offers Cloud SQL and BigQuery, and while they may not be a leader, you can accomplish what you need to and not have to leave the GCP universe that you’re already in because of Firebase. This is a HUGE win for GCP, don’t under-estimate it.

Back to Firebase. Using the logic from above, it wouldn’t really make sense for them to kill off Firebase because 1) it makes money, 2) they’re the biggest player in the category, and 3) It’s part of their cloud strategy. So no, I don’t think Google will be killing off Firebase anytime soon.

How much control do you want?

Here is an area where Firebase may not shine, but to that point alternatives may not shine either. Firebase is designed to enable app developers to reduce the amount of backend infrastructure management and thus primarily focus on their app.

This comes with the benefit of not needing to worry about the cloud infrastructure, but at the cost of losing control over that infrastructure.

If you want a high level of control, more than what Firebase offers, or see your app quickly outgrowing Firebase than it might make sense to use some features and not others. For example, you could use Firebase Auth, Cloud Messaging, and Crashlytics, but then use Cloud SQL and Cloud Run (equivalent to RDS and Fargate on AWS) instead of Firestore and Firebase Functions.

What type of auth and security do you need?

While Firebase has security rules, they are a bit limited. One option would be to use alternatives to those features where needed, but then you’re not realizing the full benefits of Firebase. For example, if you needed more fine-grained control over access to your database you could use Postgres in Cloud SQL instead of Firestore.

Another example is if you intend to build role-based authorization, you can build that with Firebase, but it is quite limited once you get past the basics. On the other hand, if that’s all you need then it will be a piece of cake. In my case, I have more than just user roles, as my app also meeds to enforce object level roles within certain parts of the app.

Pricing

Firebase will be cheaper in the short-term, as it’s free-tier will be able to accommodate your usage while in development and likely even when you have a small number of monthly active users. However, at some point it will start to become quite expensive, more so than if you were to buy the resources your self. There are two things to understand here, 1) the pricing model and how it differs from other cloud infrastructure, and 2) what you’re actually paying for with Firebase.

On the first point, Firebase (and most, if not all, serverless solutions) charge based on you’re usage, rather than availability. There are pros and cons to this, which are out of the scope of this post, and you should look them up and take them into consideration.

On the second point, paying for Firebase, and any other serverless product, is really about convenience. You’re paying for the fact that you don’t need to manage server infrastructure yourself. Again, there are pros and cons to this, which are out of the scope of this post, and you should look them up and take them into consideration.

A final note on price - be sure you’re calculating the “total cost of ownership”, meaning you also factor in your time and any other costs that will come up as a result of using a solution. Serverless, or Firebase in this case, might get expensive, but that cost may still be less than if you have to do things yourself.

Database considerations

Firebase provides a database called Firestore, which is a serverless, noSQL, option. I have found that those who will tell you not to use Firestore are usually relational database purists or don’t understand/appreciate the benefits of noSQL. To be clear, there is nothing wrong with those two things, but you shouldn’t just accept their advise and run with it.

Here are some things to consider:

1. Firestore, and noSQL document databases in general, can be great when you’re first starting out on a new project. The reason for this is that you may not know what the data model should look like when you’re first getting started, and having the flexibility to make changes without having to worry about migrations is a plus.
2. Firestore does offer realtime streaming out of the box, so if that’s something you could benefit from then it’s a good option. Though, you might consider not using it as you primary database.
3. Firestore’s query capabilities are quite limited compared to something like SQL, so if you need more powerful querying, Firestore probably isn’t the best option for you.
4. Firestore doesn’t offer a way to migrate your data. You’ll unfortunately need to query every document and save it so some file, then import it to your new database manually. This is unfortunate, as it’s not only frustrating, but also potentially very expensive.

Here’s the tech-stack I am now moving to

• Firebase for object storage, authentication, some microservices, and analytics
• Vercel for Next JS hosting, Postgres database, and Redis database

Conclusion

• You most likely don’t need to worry about Google killing off Firebase
• You should consider using Firebase if you don’t yet know all the requirements of your app and need to iterate quickly
• You should consider using Firebase when you want to focus on building your app and not worry about managing backend infrastructure
• You should consider using Firebase when you have limited resources and can’t afford to manage backend infrastructure in addition to building your app
• You should not consider using firebase if you’re worried about vendor lock-in
• As your project grows, you can “graduate” from using certain Firebase features, though the migration process might be frustrating with certain products (e.g. Firestore)
• You can choose to use certain Firebase features and not others depending on your needs