What percent of Google’s internal team uses Firebase (Firebase’s database) as opposed to a self-managed database?

A percentage would be extremely difficult to compute because one would have to survey ALL of the projects going on inside Google to get an answer. Let’s just say that Google is a very large company, which means the number of projects is of course very large, and I can’t imagine there is no one tracking all of those efforts.

But I can tell you that level of interest in Firebase is good, and it does get used internally.

Hey, what do you know, a question that I’m qualified to answer.

I feel pretty privileged to work at Google. But I feel exceptionally privileged to work on Firebase.

It’s a successful product in an area that is strategically important to the company. Its success is founded on providing easy-to-use solutions to problems that are tedious, difficult, and universal in the world of app development. Providing those solutions at scale is a hard problem. And they’re doing it. (I should say “we,” I suppose, but imposter syndrome runs deep.)

I also really enjoy the people. Firebase was, by all accounts, a positive place to work before Google bought it, and that comes from the care that the founders took in creating a culture based on self-reinforcing positive qualities, like mutual care and respect and growth through shared adversity. (For instance, said founders sit fifteen feet away from me in the middle of our noisy, distracting, exposed open-plan offices, just like everyone else, even though it’s common for Google managers at their level to have private offices.)

Firebase is really an amazing product. The Firebase team has done a great job of transitioning it into the Google behemoth while making the product even more amazing. I’ve learned a ton from working on this team so far, and I’m really excited by what I see coming down the road in the next 12 months. (Uncomfortably excited, to use Larry Page’s phrase. None of what we’re planning to do seems like it’s going to be easy.)

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.

Big websites usually use a variety of databases, because different databases serve different purposes.

You seem to misunderstand what NoSQL means. NoSQL stands for not only SQL and is the 'opposit'e of SQL. Within this categorisation, all databases fall in either SQL or NoSQL. That is, MySQL, MariaDB (open-source fork of MySQL) and PostgreSQL are SQL databases, MongoDB is an example of a NoSQL database.

As for the companies you've mentioned:

  • Facebook uses mainly MySQL. In fact, someone seems to have made an attempt to revers engineer Facebook's database design:
  • source: Facebook Object-Oriented Diagram
  • Twitter uses (their own version of) MySQL for tweets and users, and their own special kind of graph database, FlockDB, built on top of MySQL, for relations (followers, following,...), and their own version of Memcached (with speculation about whether Redis is used too or not).
  • LinkedIn used/uses Oracle Database and Voldemort.

One last thing though. Simply because these big companies use these technologies, doesn't mean that you should. They have tons of engineers and resources, and very high demands, so they can both afford to use multiple databases (which requires specialised engineers) and need to use it (because of the extreme demand). As a small-scale developer, you probably don't need to worry about the extreme demands, nor do you have the means to use multiple databases.

In a general sense, Firebase Realtime Database can be used while offline. However, the expectation is that the app is supposed to be connected most of the time, and changes to the database that happen while offline will be synchronized when it has connectivity. 100% offline use is not really a supported use case, because the canonical data store is on the server.

The local copy of the database is limited to (10MB, at least on Android this is the case). If you intend to write to the database beyond this limit while offline, it will evict part of your cached data to make room for whatever you’re adding. Then, you will no longer be able to read those evicted values until the app goes back online. Worse, managing a growing list of writes to apply when back online is taxing on the app, so you don’t want to plan a lot of writes while offline.

Also, if you have permissions or validations defined for your database, these can only be checked on the server. So, if you’re doing offline writing to your local cache and you no longer have an active listener, you may never know if those writes fail.

Because of these caveats, it’s better not to think of Firebase Realtime Database as an “offline” database. It’s better to think of it as a “synchronized” database that actively syncs to the server while connectivity is present.

The big difference between Firebase Cloud Messaging and Firebase Realtime Database is this: With messaging, you will be able to wake the device from sleep even while the app is not running. The database can only receive updates to registered listeners while the app is currently running, and if the device is not in doze mode (for Android M).

Use Realtime Database when users are in your app and actively interacting with its data.

Use Cloud Messaging for times when you don’t know if the user is in your app, but you want to get them into your app (or make your app do something at a particular moment that you decide).

Messaging also has very restricted payload sizes (4k). With Database, you can read as much as you want from any node in your structure.

I’m speaking here in a general sense for all of Android, iOS, and Chrome. Each platform has their own particular ways of handling messages, but the semantics are similar.

Clearly, they haven’t revealed it to the public & it doesn’t matter to the end-developer as well.
Although there are references that they use Mongo :
Does firebase use any kind of nosql database behind the scene like MongoDB?What backend technology enables firebase?

I had asked a question on stackoverflow regarding how firebase db stores data locally when persistence is enabled which was answered by a firebaser.
How firebase persistence stores local data for my Android app
Basically in this case the data is stored in a sqlite db the structure of which is again opaque.

Firebase is a service acquired and backed by Google Cloud (someone once told me the acquisition price was $80MM, but I cannot find evidence of that online). Yet their uptime is a fraction of ours and the many other services we depend on.

It was originally an independent company founded in 2011. In 2014, Google acquired the platform

In total, Firebase, which was founded by Andrew Lee and James Tamplin, raised about $7 million in a seed round in 2012 and a $5.6 million Series A round in 2013.

The answer really depends on the type of project you will develop and your long term goals. Here is what I like regarding each platform:


  • It’s a database like interface
  • Works with GraphQL and REST APIs
  • It’s open-source and there is no vendor lock-in
  • Easy of use and low learning curve
  • Several hosting options (AWS, Google Cloud, Azure, etc)
  • More flexible support


  • It may be the ideal choice for Realtime database projects
  • ML feature
  • Has a broader range of features
  • It’s owned by Google

If you don’t have access to any source code or any sort of data on the backend, there really is no way to tell. One giveaway might be that it is “realtime” but a ton of apps feature realtime data without using Firebase, so that is more of a “best guess” situation.

You could always just email the team that runs the app and ask, worst thing that can happen is they will say no!

An answer to this question can literally be found on the Firebase home page[1].