Can Firebase be used to create large-scale apps?

Well, I’d say the answer varies wildly for the exact use case you’re going for. So while most of the components that firebase offer to build apps are “planetary scale”, a lot of features are sorely lacking if you’re building an application on firebase features alone. Having built tens of projects, both as a hobby and as part of work I can give you a couple instances from my experience, but your mileage will vary depending on what you use firebase for.

  1. Hosting: firebase lends itself very easily to hosting thanks to the scale of Google’s infrastructure knowledge, built in CDN and SSL certificates

Well, I’d say the answer varies wildly for the exact use case you’re going for. So while most of the components that firebase offer to build apps are “planetary scale”, a lot of features are sorely lacking if you’re building an application on firebase features alone. Having built tens of projects, both as a hobby and as part of work I can give you a couple instances from my experience, but your mileage will vary depending on what you use firebase for.

  1. Hosting: firebase lends itself very easily to hosting thanks to the scale of Google’s infrastructure knowledge, built in CDN and SSL certificates and the new functions hosting that you can use for server side rendered node web apps.
  2. Fire store and real-time database: This is also massively scalable and you might find yourself using these databases even if you make the switch to other stacks just cause of the easy of use and the ability to have real-time listeners which is just such a breath of fresh air compared to MySQL or other databases. HOWEVER, this is also the part that I have the biggest issue with scalability. You just cannot do good queries with either of the databases. And this is a bigger problem than you realize and you will have to use an external system like Algolia, that has to index your database and something you have to pay extra for.
  3. Authentication: This just works out of the box and since they are effectively just wrappers around existing with providers like Facebook and google, they just work.
  4. Notifications: Having being built on Google’s Cloud Messaging system, this would also be infinitely scalable and should have no issues supporting a large app.
  5. Cloud functions: These work in a pinch when you need to run a couple functions in a server less environment, and to have an express app to host your website or to do certain tasks when data is written to or deleted from your database. HOWEVER, it has all the limitations of being a server less environment and doesn’t provide much control over its internal workings.

Having said all that, I am still an ardent firebase fan and I’ll continue using it for any projects I work on, whether at work or a personal project. And I am confident that over time, firebase will only get better with new features being added to it.

depends what do you mean by large scale, if you talking about lets say a chat app, or an app reminding you to take care of your plants or something that can order form a restoring (basically any app with under 15 screens) and you want to be able to support a minion daily users - Firebase no problem

If you talking about a company with few hundred or thousands of employees that work with customers and do thousands of transactions every day or basically any system that needs to run a company with 20+ people you better stay away from Firebase

I have done few large scale business systems and the most

depends what do you mean by large scale, if you talking about lets say a chat app, or an app reminding you to take care of your plants or something that can order form a restoring (basically any app with under 15 screens) and you want to be able to support a minion daily users - Firebase no problem

If you talking about a company with few hundred or thousands of employees that work with customers and do thousands of transactions every day or basically any system that needs to run a company with 20+ people you better stay away from Firebase

I have done few large scale business systems and the most important thing after the actual functionality of the system is the reporting, all the ways you can extract value from the data the system is collected - that is done best with a SQL transactional DB and firebase is a Non SQL Document based DB

Let me know what are the specifics of your project, I may be able to help

Firebase is intended for use with apps that need to scale. Watch my session at Google I/O 2018 called “Build planetary scale apps with Firebase”.

Cloud Firestore, Cloud Storage, Firebase Hosting, and Cloud Functions are all what you might consider “massively scalable”, and require little to no effort from the developer to make that happen.

First, when talking about databases in the Firebase suite, I’m only going to talk about Firestore, and not RTDB (Realtime Database, which was traditionally known as just Firebase). Firebase now refers to an entire suite of services, which includes Firestore, RTDB, file storage, authentication, etc. RTDB is most likely going to be phased out and Google is clearly putting their effort behind Firestore.

Second, there is no manual sharding in Firestore, like there was in RTDB. Sharding is handled automatically by Firestore, so ignore the other answers about that.

Third, you, the customer, own the da

First, when talking about databases in the Firebase suite, I’m only going to talk about Firestore, and not RTDB (Realtime Database, which was traditionally known as just Firebase). Firebase now refers to an entire suite of services, which includes Firestore, RTDB, file storage, authentication, etc. RTDB is most likely going to be phased out and Google is clearly putting their effort behind Firestore.

Second, there is no manual sharding in Firestore, like there was in RTDB. Sharding is handled automatically by Firestore, so ignore the other answers about that.

Third, you, the customer, own the data in your Firestore database, not Google, so ignore the other answers about that also. If Google, and not the customer, owned that data, Firebase would have virtually no users. And, also contrary to the other answers, you can export data from Firestore. If customers weren’t allowed to export their data, who would ever use it?

Fourth, the suggestion to use SQL technology on your own physical servers (ones that you physically own) is not something that I think belongs in an answer to this question. SQL vs NoSQL and cloud vs in-house are decisions that you should have already made if you’re asking about a specific serverless provider. Clearly (at least apparently), you’ve decided on serverless NoSQL, which is definitely the most popular choice today. And between the two most popular providers, AWS and Firebase, they are designed to handle virtually any workload you throw at it. The most highly-trafficked applications in the world run on NoSQL serverless, like the Amazon marketplace, for example (AWS, obviously). If AWS can handle it, Firebase can handle it too. Google would never design its NoSQL serverless to max out at a certain number of users or level of traffic; it’s designed to scale virtually infinitely.

The only caveat to Firestore (and NoSQL serverless in general, really) is dollar cost—right now in 2019, anyway. Firestore was considerably more expensive only a year ago than it is today, think about that. I think NoSQL serverless will undoubtedly continue to become cheaper, including Firestore. But, right now, with a relatively large userbase, NoSQL serverless, like Firestore, can get expensive. But so can doing it all in-house. An in-house solution still comes with bandwidth cost, in addition to hardware and human cost. Hiring qualified backend engineers to build and maintain an in-house setup is not cheap (hundreds of thousands of dollars a year). Firestore (and DynamoDB) have excellent price calculators to help you predict your costs and you may be surprised to see how cheap it is with a modestly-sized userbase, even with 100k users.

This is a question I get from a lot of clients as many of our products rely heavily on Firebase. The answer is very dependant on your application but in almost all cases this will never be a problem.

Where do the costs occur?

If you look at the Firebase pricing plan you can see that data is the main constraint for the pricing brackets. When you move up a tier you get various increases in data allowances as well as more database operations. This means you need to look at what your app does to see the impact of more users.

What does my app do?

This is the next question you need to ask yourself. Many

This is a question I get from a lot of clients as many of our products rely heavily on Firebase. The answer is very dependant on your application but in almost all cases this will never be a problem.

Where do the costs occur?

If you look at the Firebase pricing plan you can see that data is the main constraint for the pricing brackets. When you move up a tier you get various increases in data allowances as well as more database operations. This means you need to look at what your app does to see the impact of more users.

What does my app do?

This is the next question you need to ask yourself. Many apps will be dealing only in text strings meaning the data amount is very small. Images would be a step up from this and videos another jump in data usage. You need to think about how often your app stores this data. It might be that you only upload a single image for each user or it could be that you send multiple images while using. In both these cases the data usage will vary hugely.

Before worrying about how you will cope with 1M users think about how the app will fare with 1–10k users. In Firebase’s case you will probably be on the free tier (as long as you are not guzzling data) up to 100k users.

Think about this for a moment. You will have 100k users on your app. Even if you only add advertising you should be able to make the $25 a month to cover the Firebase FLAME costs.

The motto I use with my clients is this:

By the time you need to start worrying about backend costs for your app you can stop worrying about backend costs for your app

Once you reach the amount of users to requiring you to start payment you will have a successful app with a big user base which can be leveraged to start paying you back.

Should I use Firebase?

This is the final question you should ask yourself. Up until now this question could have been about one of the many different backends on offer.

If you are unsure I would be inclined to say: YES use Firebase!!

They are a great company and offer a fantastic product. Being owned by Google and having recently updated all their code they are unlikely to close down (RIP Parse). They also provide extensive and clear documentation and great support. There is a huge online community meaning sites like this and Stackoverflow have a huge number of questions to help you.

It is worth looking at your app though. Firebase does have some disadvantages:

  1. There is no easy way of querying data
  2. There is no way of executing code on the server

This is what should be researched when looking at whether Firebase is the right backend for you and even these can be mainly mitigated by using a separate server to control these tasks.

Conclusion: Unless your app is very data intensive then you won’t meet any of the data caps. Firebase will help you get your app online quickly and cheaply before scaling excellently once the users start pushing the upper limits.

NOTE: I would never recommend someone building their own backend when starting a new app. It might be that you have the skills to do it but in the long run it will cost you more (in your valuable time) than using another provider. Once your app is a great success and you are paying monthly fees to a backend then you can invest the money in creating a custom backend which suits your data type. Creating it yourself also requires a huge amount of invested time. If your app fails then this time is completely wasted.

There are several reasons not to avoid using Firebase and several reasons to avoid it altogether. Since you asked, the main reasons to avoid it are the following:

  • Outages: Firebase Realtime database seems to runs on a single zone and if it fails you cannot do anything but wait for it to recover and outages surely do happen.
  • Scaling: If your service grows a lot, you will start facing serious performance issues in reading and writing to the Realtime database.
  • Multiple environments: While Realtime has an emulator you can use for development, it comes with important limitations. The best solution see

There are several reasons not to avoid using Firebase and several reasons to avoid it altogether. Since you asked, the main reasons to avoid it are the following:

  • Outages: Firebase Realtime database seems to runs on a single zone and if it fails you cannot do anything but wait for it to recover and outages surely do happen.
  • Scaling: If your service grows a lot, you will start facing serious performance issues in reading and writing to the Realtime database.
  • Multiple environments: While Realtime has an emulator you can use for development, it comes with important limitations. The best solution seems to be to have a second project to use as a development/staging environment. Of course, if you want to have a few development environments plus a staging one before you roll out to production it starts to get messy. Being able to replicate your production environment using docker containers does make life and collaboration easier and you can’t do something like this with Firebase.

Nonetheless, I would not recommend just setting up your own backend and having to do software patches etc as some people imply is the alternative. The alternatives include using more scalable databases such as BigTable or ScyllaDB which can be used as a turnkey solution and then using things such as Cloud Functions, App Engine or Docker containers along with Kubernetes for your backend services. Just make sure that you encapsulate and abstract calls to your queues and databases so that you are not tied up in any one technology.

Of course, there are also very good reasons to use Firebase:

  • Authentication: Firebase takes care of your authentication allowing for different authentication methods that work on all devices. This makes life a lot easier.
  • On(change, add, delete etc.) Events: Realtime database is just amazing for frontend updates. You subscribe to data changes and the moment something changes in the database, your frontend updates instantly.
  • Cost: Especially in the beginning, it costs next to nothing to get started. As your app scales you start to feel the cost but in order to have a system that offers what Firebase offers you will be paying in any case so it is good to be able to start with very low fixed monthly costs and paying based on usage.
  • Speed of Development: Firebase allows you to launch your MVP in no time. It is not the best for large teams and complex projects but for MVPs it is just fantastic.

Yes you can. It’s highly scalable, perhaps among the most scalable NoSQL solutions.

It can be very non-scalable if you simply treat it as JSON though. When working with JavaScript in your browser it’s not exactly bad practice to create JSON objects and datasets with deeply nested branching structures. It makes accessing the data from your script and front end really straight forward. When you build your entire database using JSON though, you have to build in some of the benefits of RDB. You should maintain a very flat structure with minimal nesting of large datasets. The reason is that each tim

Yes you can. It’s highly scalable, perhaps among the most scalable NoSQL solutions.

It can be very non-scalable if you simply treat it as JSON though. When working with JavaScript in your browser it’s not exactly bad practice to create JSON objects and datasets with deeply nested branching structures. It makes accessing the data from your script and front end really straight forward. When you build your entire database using JSON though, you have to build in some of the benefits of RDB. You should maintain a very flat structure with minimal nesting of large datasets. The reason is that each time you retreive a node, you retreive all the stuff under it.

Imagine you have an object like this:

  • Thing-1
    • Property-of-thing-1
    • List-of-sub-things
      • complex objects
      • complex objects…
      • etc…
  • Thing-2
    • same idea….

Now each time you get Thing-1 or Thing-2, you also get every single object in that sub list even if you don’t need them.

You should do something like this instead:

A list of things:

  • Thing-1
    • Property-of-thing-1
    • List-of-sub-things
      • Complex-object-id-1
      • Complex-object-id-2
      • etc…
  • Thing-2
    • same idea…

A list of sub-tings:

  • Complex-object-id-1
    • combplex objects…
  • Complex-object-id-2
    • complex objects…

This way you can get Thing-1 and just access Property-of-thing-1 for a title or something. If you want all the other data for a details view or whatever, you access that using the id of all the details…

Good luck building awesome scalable apps!

Pro’s:

1. If your app does run of a centralized DB, and is updated by a lot of

users – then it’s more than capable of handling the Real-Time data

updates between devices.

2. Stored in the cloud so readily available everywhere.

3. Cross Platform API (If you are using this DB with an App)

4. They Host the data. -Meaning if you are storing a lot of data, you don’t have to worry about hardware!

Con’s:

1. Unless your app runs of one centralized database updated by a vast quantity of users, it’s a major overkill.

2. Storage format is entirely different to that of SQL, (Firebase uses JSON) so you wouldn’t be

Pro’s:

1. If your app does run of a centralized DB, and is updated by a lot of

users – then it’s more than capable of handling the Real-Time data

updates between devices.

2. Stored in the cloud so readily available everywhere.

3. Cross Platform API (If you are using this DB with an App)

4. They Host the data. -Meaning if you are storing a lot of data, you don’t have to worry about hardware!

Con’s:

1. Unless your app runs of one centralized database updated by a vast quantity of users, it’s a major overkill.

2. Storage format is entirely different to that of SQL, (Firebase uses JSON) so you wouldn’t be able to migrate that easily.

3. Reporting tools won’t be anywhere near the ones of standard SQL.

4. Costs! -Limited to 50 Connections and 100mb of Storage!

5. You don’t host the data, Firebase does. And depending on which server you get put on, viewing there up time there seems to be a lot of disruption lately.

Read more at: What are the advantages and disadvantages of Firebase for a database? - FAQs System

Yes but you will burn way too much money. Why?

Firebase is a general purpose very easy to use Api and so are the features. Very easy to use but not too rich of functionality. (you cannot get complex queries with Firebase e.g.)

You will easily build a Instagram Clone. However, at a certain point it’s simply too expensive and you’re better off developing your own stack to serve your needs efficiently.

Conclusion: Build an MVP with Firebase if you have no idea about backends. If your app gets traction you can easily transition to your own stack. (Most of the times you won’t get traction so there’s n

Yes but you will burn way too much money. Why?

Firebase is a general purpose very easy to use Api and so are the features. Very easy to use but not too rich of functionality. (you cannot get complex queries with Firebase e.g.)

You will easily build a Instagram Clone. However, at a certain point it’s simply too expensive and you’re better off developing your own stack to serve your needs efficiently.

Conclusion: Build an MVP with Firebase if you have no idea about backends. If your app gets traction you can easily transition to your own stack. (Most of the times you won’t get traction so there’s no need to waste time implementing your own stack)

Firebase isn’t a database. Firebase is an app hosting engine. Firebase applications are able to use Cloud Firestore. Firestore will scale performance up as you need it, but you need to be very aware of the pricing constraints. You really should look into the details yourself, but the tl,dr is:

  • Fairly cheap storage ($0.18/GiB/mo)
  • Not cheap writes/reads ($0.18/100K for writes, less for reads and deletes). It’s not a deal-breaker, but you have to be very aware of your query structure to avoid racking up excess queries.

The query patterns are going to be far more important here than your absolute dat

Firebase isn’t a database. Firebase is an app hosting engine. Firebase applications are able to use Cloud Firestore. Firestore will scale performance up as you need it, but you need to be very aware of the pricing constraints. You really should look into the details yourself, but the tl,dr is:

  • Fairly cheap storage ($0.18/GiB/mo)
  • Not cheap writes/reads ($0.18/100K for writes, less for reads and deletes). It’s not a deal-breaker, but you have to be very aware of your query structure to avoid racking up excess queries.

The query patterns are going to be far more important here than your absolute database size (100GB with 100 queries a day is going to be pretty cheap, but 10GB with 10,000,000 queries/day isn’t).

It looks like Firebase/Google has resolved the problem in an update, but as someone who is naturally paranoid, I second the motion of making sure that your back end infrastructure can be swapped out no matter the SaaS provider.

Yes, it's more work. But ultimately it's worth it.

If they hadn't gotten the attention of someone who could fix things, they would have been out a lot of money, or their service would have been killed. And of all of the positive things that I can say about Google, good customer support doesn't make the top 100.

I'm still planning on using Firebase for various products movi

It looks like Firebase/Google has resolved the problem in an update, but as someone who is naturally paranoid, I second the motion of making sure that your back end infrastructure can be swapped out no matter the SaaS provider.

Yes, it's more work. But ultimately it's worth it.

If they hadn't gotten the attention of someone who could fix things, they would have been out a lot of money, or their service would have been killed. And of all of the positive things that I can say about Google, good customer support doesn't make the top 100.

I'm still planning on using Firebase for various products moving forward, but will continue to keep my servers in the loop.