Should I use Google Firebase for my startup?

It’s a great solution for authentication, including multi-factor. The real-time database combined with a React or similar app is a great user experience. The functions and other services, now with ML, make it a very rich toolset.

Be sure you know how to model data and follow their recommendations in the docs (using object instead of arrays). Use the bulk update whenever possible and if over a hundred writes per second, chunk the updates.

Be sure to watch the video on the security rules and validation features. If you study and leverage these it will minimize code you have to write for input vali

It’s a great solution for authentication, including multi-factor. The real-time database combined with a React or similar app is a great user experience. The functions and other services, now with ML, make it a very rich toolset.

Be sure you know how to model data and follow their recommendations in the docs (using object instead of arrays). Use the bulk update whenever possible and if over a hundred writes per second, chunk the updates.

Be sure to watch the video on the security rules and validation features. If you study and leverage these it will minimize code you have to write for input validation and authorization.

Use the push syntax to generate unique, sequential IDs.


Dont force using NoSQL however. Some use cases are best served with ACID compliant DBs (I.e. banking, accounting, users).

Depends on the startup, of course. In general, Firebase lets app developers launch and iterate quickly and cheaply relative to every other mechanism for doing so I’ve seen or heard of.

I think the concern about lock-in is valid but easy to overstate. If you want to run your own real-time notification and crash analytics platform (say), you can spend two years building that before you launch your app, or you can launch your app and then decide whether or not you need to build your own platform. Those kinds of investment decisions get a lot easier to make if you already know that your startup is

Depends on the startup, of course. In general, Firebase lets app developers launch and iterate quickly and cheaply relative to every other mechanism for doing so I’ve seen or heard of.

I think the concern about lock-in is valid but easy to overstate. If you want to run your own real-time notification and crash analytics platform (say), you can spend two years building that before you launch your app, or you can launch your app and then decide whether or not you need to build your own platform. Those kinds of investment decisions get a lot easier to make if you already know that your startup is viable.

(These are my opinions, not Firebase’s. Firebase’s opinions are generally smarter and more knowledgeable than mine.)

It depends of course what kind of startup you have and what are you needs. If startup is based or dependent on some mobile / web application, than Firebase is good choice. Keep in mind, that Firebase is it’s own world so it takes time to get to know platform, functionalities. Other thing which you should be aware is that, it’s potential lock in, i.e. if for some reason you’ll want to migrate away, it wouldn’t be so simple. If you want to develop rapidly application then Firebase is worth of trying.

Good: You will have record speed of getting and iterating on MVPs. Deployment, Analytics, and scalability will be amazing. I use React + Firebase and it has been fantastic.

Bad: Firestore (the DB) is a little wonky and while fast I don’t love it. The top 10 things to know about Firestore when choosing a database for your app. Also your costs can get out of control fast if you are growing. You’ve have to manage your usage vs costs (Firemon - control your Firebase costs). But isn’t that a good problem to have?

You can, but keep in mind that if you become big, you will have to switch to a private server. For initial design though, it is a good option as it is cheap and easy to use.

Personally, yeah. But that’s a very broad statement. Firebase offers MANY services, and I can bet that at least one of them will be useful for your app/software. Real-time database, file storage, functions, Crashlytics (integration with Fabric) are just some of the features offered.

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.

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.

Firebase is a NoSQL cloud database. A NoSQL database provides a mechanism for storage and retrieval of data that is modeled in means other than the tabular relations used in relational databases.

The Firebase Realtime Database is a cloud-hosted database. Data is stored as JSON and synchronized in realtime to every connected client.

Since you particularly asked for Firebase Database, I would be focusing on that only from many features of the Firebase.

Key Features of Firebase Database

  • Real-time

Instead of typical HTTP requests, the Firebase Realtime Database uses data synchronization—every time data

Firebase is a NoSQL cloud database. A NoSQL database provides a mechanism for storage and retrieval of data that is modeled in means other than the tabular relations used in relational databases.

The Firebase Realtime Database is a cloud-hosted database. Data is stored as JSON and synchronized in realtime to every connected client.

Since you particularly asked for Firebase Database, I would be focusing on that only from many features of the Firebase.

Key Features of Firebase Database

  • Real-time

Instead of typical HTTP requests, the Firebase Realtime Database uses data synchronization—every time data changes, any connected device receives that update within milliseconds. Provide collaborative and immersive experiences without thinking about networking code.

  • Offline

Firebase apps remain responsive even when offline because the Firebase Realtime Database SDK persists your data to disk. Once connectivity is reestablished, the client device receives any changes it missed, synchronizing it with the current server state.

  • Accessible from Client Devices

The Firebase Realtime Database can be accessed directly from a mobile device or web browser; there’s no need for an application server. Security and data validation are available through the Firebase Realtime Database Security Rules, expression-based rules that are executed when data is read or written.

  • Scale across multiple databases

With Firebase Realtime Database on the Blaze pricing plan, you can support your app's data needs at scale by splitting your data across multiple database instances in the same Firebase project. Streamline authentication with Firebase Authentication on your project and authenticate users across your database instances. Control access to the data in each database with custom Firebase Realtime Database Rules for each database instance.

Real World Usage

I've personally used Firebase in number of applications and it is very fluid in its working. It is highly efficient if you want a real-time database that is synced across every client.

Other useful features of Firebase includes -

  1. Cloud Messaging (FCM)
  2. Authentication
  3. Cloud Firestore
  4. Storage
  5. Hosting
  6. Cloud Functions
  7. Crashalytics
  8. Performance Monitoring
  9. Test Lab
  10. Crash Reporting
  11. Predictions
  12. Remote Config
  13. Dynamic Links
  14. App Indexing
  15. AdWords
  16. AdMob

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 co

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.