Is firebase DB scaleable at an enterprise level application?

No, for enterprise-grade application, firebase is not a good choice and not scalable as well.

Firebase is good choice till it’s not your primary database and you use it for the limited purpose where it shines.

Here is the list of limitations so you can decide on yourself.

  1. Big limitations written on their own documents:
    1. Firebase itself says that “Complex, hierarchical data is harder to organize at scale.” (The same can be referred on their doc here.)
    2. You can only sort or filter on a property, not sort and filter on a property, in a single query. (Reference)
  2. Firebase Real-time Database queries do not support WHERE clause.
  3. The major disadvantage is we can not query for more than one key/id at a time.
  4. Firebase can only sort ascending, not descending.
  5. Different combinations of select query criteria requires multiple times data duplication.
  6. One would never be able to filter one's data, this is a big pain at this stage.
  7. IP restriction is not supported.
  8. Fetching data of multiple users is not supported.
  9. Database structure needs to be changed on every little requirement change. Eg. If we want to change sorting order then existing any DB structure will be of no use.
  10. Firebase Real-time Database is built on a funda of Data Duplication (Denormalization) and due to this, it keeps increasing the overhead/load on clients and servers for keeping all the copies of data updated whenever there is a change in data values.
  11. child_added listener fails to provide the previous record Id when records are being inserted back to back (e.g. chat messages).
  12. Certain query options can't be combined. Because of this limitation, it forces us to either sort the documents by date or filter them with the user's search query on the database side and perform the other action on the client side.
  13. Complex queries are impossible. For instance, we want to build a Slack-like app: we cannot count unread messages, even if we have the proper structure that would allow doing so (eg: a read = <true|false> tag). The hack is to count all unread messages client-side, after having retrieved the whole dataset. It's a huge performance issue. It will increase the usage cost at user-end due to the high amount of internet consumption.
  14. As query filters are not supported, the large amount of data transmission occurs over the network for all the clients and servers communicating with database.
  15. With Firebase, we can not paginate because we can not get query array length, we can not paginate ordered arrays, etc.
  16. It has disadvantages if we are managing large amounts of highly structured data. With a regular relational database we can write powerful queries in SQL to quickly get the data we looking for - there is no equivalent with Firebase.
  17. We can not use ORM (Object-relational mapping) with Firebase to simplify data handling.
  18. As parent-child relation not supported, dealing with relations with Firebase is a pain. e.g. An user belongs to a group, and a group has users.
  19. With embedded platforms, REST API’s of Firebase cannot be implemented quickly.
  20. Firebase does not support simple Geo queries.
  21. Firebase is also not ideal if the application requires continuous processing on server side (especially when data has to be analyzed before there is some display to users real-time based on the result).
  22. Firebase definitely doesn’t support transactions.
  23. As all clients can connect directly with the database and can update data, all the clients become responsible for keeping data consistent which sometimes end-up with uncontrollable system behavior.
  24. Without a back end, supporting Web, iOS, and Android means rewriting business logic and data transformation numerous times.
  25. Using Firebase means that all the server logic is now running right in web or mobile client.
  26. In most apps, we have to send welcome emails, process images (avatars, etc), deal with payments, and build our business-core features. We really don't want all those to be done on the client, as this can range from impossible to dangerous for our business.
  27. If we think about distribution: any database logic change results in client app updates. How do we deal with clients who didn't update? Is it a correct thing to do for our users to deactivate older clients to force an update?
  28. With Firebase, it is impossible to expose API for our product.
  29. MIS (or any kind of) report generation becomes very difficult with Firebase database as there is no support of querying on multiple tables.
  30. No reliable tools are available to visualize and manage data. (e.g. SQL Server Management Studio, MySQL Workbench, etc.)
  31. We don't have root access to the location where our data is stored.
  32. No on-premise installation.
  33. Reporting tools are not strong enough in Firebase.
  34. Firebase users are vendor-locked.
  35. We can't shop around for which hosting provider to use.
  36. No case studies of enterprise level usage of Firestore.
  37. Firebase is a mobile-first offering. It was designed for mobile apps (Android, iOS, and web where sensible), and favors projects with a focus on mobile usage.
  38. Cost: Paying $100 per month to Firebase for something we can run on a $5 DigitalOcean droplet is something that gets us to think twice when dealing with server-less code.
  39. It's harder to migrate to a different service.
  40. There is no development roadmap for adding new features/capabilities in the future.
  41. We have filed some cases with Firebase support but they haven't provided any solution. Also, they are denying to provide ETA for all the support or feature requests. And with the launch of Firestore, it is highly doubtful that they will continue on enhancing and maintaining the Realtime database.
  42. It is not supported in China.
  43. Reasons Not To Use Firebase (a true story of Crisp chat system)
    1. Reasons Not To Use Firebase (Reasons Not To Use Firebase)
  44. Why I’m dumping Firebase for Web? - Michael Lugassy (Founder of Ad Tech is broken. We fix it!. Built 7 other companies, sold 3, worked with dozens more.)
  45. Why I’m dumping Firebase for Web? (Why I’m dumping Firebase for Web?)

So I would not say it’s bad but if you want firebase everywhere then welcome my friend, you are in hell.

Happy Coding,

Ridham Tarpara

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.