How many visitors does Firebase support in free and paid plans? Is Firebase costly?

Firebase has three plans, one of them is free called Spark Plan. Using this free plan you can have only 100 active users at once, only 10GB data to be transferred within one month and store only 1 GB of your data. i.g. you have an online web store: only 100 users can be there at once, only 1 GB of data (title, price, image of item) can be stored in DB and only 10 GB of transfer - means that your web site will be available to deliver to users only 5gb of data (i.e. your page is 1 MB size and users will be able to attend that page only 10 000 times).

And providing 10 Virtual Device Tests per day and also 5 Physical Device Tests per day.

Other two paid planes are -

  1. Flame Plan - $25/month
  2. Blaze Plan - Pay as you go

You can check those planes from here[1].

Footnotes

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.

Firebase is, essentially, a key-value store that you can use to quickly prototype and run a simple application, either native mobile or in-browser javascript.

They include all the authentication stuff and website hosting, so it takes away a lot of the pain of getting started and allows you to get something up and running really quickly. I haven’t played with it very much, but from what I’ve seen and heard it is a fantastic product!

What Firebase will not do for you, however, is any business logic on your stored data. You would have to incorporate that into the front-end application, which for complex stuff is simply not a viable option.

If you’re making something cool that just needs a fast, reliable database, user authentication and usage tracking, then Firebase is a great way to go. If you’re building something that has complex back-end business rules then you’re going to run into difficulties.

You can totally combine it with a custom application of course, store your data in Firebase and have a middleware layer that does the business logic, but for most business cases this isn’t really a good compromise.

In short NO

Firebase is a good option but if you want to create a CMS and use it real-world application then consider these below points before starting.

1.Ease of use

Yes, firebase is easy to use no doubt in that. But when using it in a real application than you will face many complications. For Example:

Limited option is available for Firebase. Like if you want to add a search query in the firebase then hard luck doing that as there is no direct way of don't that.

2. Cost
Firebase is lucrative when starting out with its free tier but as your users grow your bill will grow exponentially.

3. You will get stuck

It is impossible to switch your firebase backend if need be. Like if you are on a SQL database you can easily switch to any other variant and service providers when you need it. But with firebase, you will get stuck with it.

So in my opinion, if you are making a data-driven app like blogs or tutorials or anything like that then look somewhere else. But if database is a secondary functionality of your software like a photo editor or similar app then you can use firebase.

MongoDB vs Firebase. When comparing MongoDB and Firebase, it is important to consider all the factors related to Document database. For an entrepreneur, choosing a technology stack can be a difficult thing. It is necessary to consider the front-end and back-end requirements of your App development. Especially, keen attention should be given to the database, as all the important data, details and documents are stored in it.

Every database provides features and solutions to different problems and needs. You just need to understand the requirements of your application development to choose the perfect fit. Here are few things to consider when choosing a database for web or app development. First of all, make sure that all the basic requirements of the database are satisfied. Then, list the requirements of your app development and check if that is justified. And compare tools before finalizing one. Here is such a comparison between MongoDB and Firebase.

Read the full article here: MongoDB vs Firebase. Which is Better For Your Business

As of today there are two plans: Spark (free) and Blaze (pay-as-you-go). The Spark plan is pretty generous, but once you go beyond the free quota limit you need to manage your Firebase costs.

When you consider your app size, think about:

  • Size of data and egress (are you storing large video files you’ll be streaming)
  • Website hits + database reads/writes
  • Long processing tasks - Cloud Functions

vs your growth in revenue. If you are paying $1,000 a month for Firebase, but brining in $50,000 a month, that might be ok. If you are paying $100 a month and have no revenue…maybe an issue. In other words, if you have a large app with growing revenue, it might be ok.

Now for managing and controlling your Firebase costs, I would point out this article on Understanding Firebase Costs and my company, fireRun.io, that actually helps you see and manage your Firebase costs.

Firebase Pricing

Firebase has both 1 free and 2 subscription options:

Firebase provides the best back-end server, great database and analytics solution, and useful integrations with other Google products. Most of all, users like that it’s free to use and has affordable subscription options. A wisely designed CMS solution guarantees project scalability and data security. In the development process, up to 40% of efforts are made on building a flexible CMS structure and Admin panel. So, if the features of Firebase Free plan are enough to achieve your final goal, then you may save up to 40% of your budget and also time.

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.

I am using Firebase for my app which has around 4500 downloads for 3 months now on Playstore and monthly 2.5k active Users. I am currently on Spark plan and so far things have been pretty good. I had enabled offline sync in my app that comes out of the box from the Firebase SDK since the beginning but when users grew in number my usage limits are very high, I think I have to move to Blaze or Flame now.

I use the following components from Firebase:

  1. Real time database
  2. Cloud functions
  3. Storage
  4. Crash reporting
  5. Dynamic links
  6. Remote Config
  7. Notifications

Few problems that I faced:

  • I felt the SDK’s and the whole system is tightly coupled.
  • Not much insight on how the SDKs worked until they open sourced it during IO 2017
  • Sometimes I used to get errors while deploying cloud functions and they get resolved in an hour or two.

Because of an adjustment by they way they report information use, our month to month costs for Firebase, a SaaS gave by Google, has expanded from $25 every month to what exactly is currently moving towards the $2,000 mark — without any progressions to our real information use. This change was made all of a sudden.

You'll have to check their website but most features are free, with some only costing money when you go over the free use limit.

For example some features allow x amount of data calls per month. The bottom limits are actually quite high making firebase amazing for scaling.

I've personally use firebase for everything I can.