How fast is firebase?

You don’t seem to know much about Firebase, from your mention of “million rows”. Firebase uses a document storage (JSON Documents), similar to MongoDB, so there are documents with fields and sub documents, and nothing like rows or tables.

Back to your question, yes Firebase is blazingly fast. I’ve used Firebase in building two apps of mine, and the response is amazing. Remember, Firebase by default uses promises so you’re able to go on with your app, whiles you wait for the data from Firebase.

One thing to keep in mind is how to do proper queries, so as to retrieve only what you need to the clie

You don’t seem to know much about Firebase, from your mention of “million rows”. Firebase uses a document storage (JSON Documents), similar to MongoDB, so there are documents with fields and sub documents, and nothing like rows or tables.

Back to your question, yes Firebase is blazingly fast. I’ve used Firebase in building two apps of mine, and the response is amazing. Remember, Firebase by default uses promises so you’re able to go on with your app, whiles you wait for the data from Firebase.

One thing to keep in mind is how to do proper queries, so as to retrieve only what you need to the client. How fast you can load data will depend on how much data you’re pulling, and your network, so if you go pulling down documents of 10 gig in total, I hope you wouldn’t expect Firebase to do any magic to get them fast to you.

Rest assured, Firebase is from Google, and hosting your app on Firebase and using Firebase realtime database is fast enough.

Firebase is real-time. Not kidding, whenever something changes in the DB it updates all the clients listening in real time.

You can’t really create complex queries, since they have a limit of 1 `orderBy()` function.

But you shouldn’t be too worried about that, since in noSQL you should optimize your data for reading, that means duplicating your data is a good practice.

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.

I have to assume that your usage is towards the high end, since it doesn't get any more economical than free, which is what it costs at the low end.

The first question you need to answer is, what is so expensive?

The classic real time database in Firebase is pretty terrible from a best practice standpoint. You often need to duplicate data multiple times to make it available in all the ways you need to access it. Much of your code can end up managing all the data duplicates; you effectively end up creating indexes in code instead of letting the database do the work for you.

So one way to save mone

I have to assume that your usage is towards the high end, since it doesn't get any more economical than free, which is what it costs at the low end.

The first question you need to answer is, what is so expensive?

The classic real time database in Firebase is pretty terrible from a best practice standpoint. You often need to duplicate data multiple times to make it available in all the ways you need to access it. Much of your code can end up managing all the data duplicates; you effectively end up creating indexes in code instead of letting the database do the work for you.

So one way to save money might be to transition to Google Cloud Firestore, or to Amazon DynamoDB, or even to a relational database. Amazon has managed Postgres in their RDS for instance.

It's hard to beat Amazon S3 for storing static assets.

If you need auto data replication, there are databases like CouchDB and CouchBase that can sync to web and mobile. Both are really easy to scale as well. Running a cluster on EC2 instances may end up cheaper than Firebase if your usage is high. If you want a managed service, Compose[1] has a managed RethinkDB offering.

Google Cloud Functions can be great for simple things, but they charge for GB-seconds and CPU-seconds. If the functions you've defined are idle a lot of the time waiting for database operations, you may be overpaying. Sometimes it makes more sense to run a server on an EC2 instance or scaling using an ECS/EKS cluster. Node.js is capable of handling a lot of idle connections at once. Golang is capable of handling even more, though, so if you have a really hot code path, a Go server might be even cheaper.

And then there's caching. Sometimes you can save a lot of money by using an in-memory database to reduce your database usage.

And then there's architecture. Your app may be doing things in a way that uses 100x as much of the billable Firebase services as it needs.

So in summary, there are a lot of ways to reduce your server costs. I once worked with clients to reduce hosting from $10k/month down to $500, and I've rebuilt architecture to enable scaling and high performance when the original developers didn't even bother creating an even moderately scalable design.

If you're actually asking for something exactly like Firebase that's a drop-in replacement that's cheaper? Again, you'll need to know why your app is costly, and then compare to the other options. [2]

Footnotes

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

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

Please don’t listen to the “proprietary blabla”. This is bs.

Imho MBaaS is the biggest failure ever made. No one ever will make money (long term) out of it. Their biggest failure, as you see in this post is, they don’t understand people like you. They think you will be a paying customer at some time. (This is never going to happen)

Now, let’s solve your problem. You’ve got that great idea and want to get going quickly. You seem like passionate about it. You want to focus on front end, not backend, means you focus and know your weaknesses. Very good point to start at!

So, why is Firebase your perf

Please don’t listen to the “proprietary blabla”. This is bs.

Imho MBaaS is the biggest failure ever made. No one ever will make money (long term) out of it. Their biggest failure, as you see in this post is, they don’t understand people like you. They think you will be a paying customer at some time. (This is never going to happen)

Now, let’s solve your problem. You’ve got that great idea and want to get going quickly. You seem like passionate about it. You want to focus on front end, not backend, means you focus and know your weaknesses. Very good point to start at!

So, why is Firebase your perfect solution? It’s supported by google. It’s super super easy to use. It’s well documented. Any more questions?

You can build whatever app (prototype) with Firebase in no time. It might not scale, but this is not what’s it about. You just want to master front-end stuff, don’t you? Right.

Eventually your MVP might get traction. What are you going to do? Well, if it’s going to get “a lot” of traction, you can pay someone to build a scalable backend for you. If not, scalability will never be an issue. You just don’t have to care about it!

Build whatever you like. Focus on the things you love to do. Firebase let’s you do exactly this. Keep it going, cheers.

Hi,

I would like to answer this by sharing a real life experience. We created an IoT platform in my company named 700 Dollar Startups. It allows users to control home appliances using their smartphone. The platform also collects temperature and air parameters at your home.

We settled to use the following stack:

  • Firebase - for backend
  • Angular JS - FrontEnd
  • NodeJS - to run IoT code in raspberry
  • Ionic - for the mobile app

Below is our platform architecture.

Here are the advantages based on our experience:

  1. Three way binding - Firebase API solves the problem of raise condition in database. A client browser,

Hi,

I would like to answer this by sharing a real life experience. We created an IoT platform in my company named 700 Dollar Startups. It allows users to control home appliances using their smartphone. The platform also collects temperature and air parameters at your home.

We settled to use the following stack:

  • Firebase - for backend
  • Angular JS - FrontEnd
  • NodeJS - to run IoT code in raspberry
  • Ionic - for the mobile app

Below is our platform architecture.

Here are the advantages based on our experience:

  1. Three way binding - Firebase API solves the problem of raise condition in database. A client browser, back-office, and mobile consumer can update a data simultaneously without the problem of synchronization. As soon as data is updated, added, inserted, or deleted all update are automatically pushed to the client via API.
  2. Speed of Development - Google Firebase Database is NoSQL database with out of the box API connectors and wrappers for query purposes. As a result, rather than building REST API just like the traditional way of connecting thin client to database, with Firebase, a company can simply use their SDK to do the same purpose. As a result, business would be able to cut their development time by removing the API development component. Less scope, means less development cost as well.
  3. Realtime update - The old ways of doing things is that a client connected to database need batch update to get new sets of data. It is an inefficient architecture, imagine a program has to read 1 million records every fifteen (15) minutes with or without update. With Google Firebase Database, a client can be automatically triggered for refresh via Callback as soon as an update is made in the database. With thus technology, developers are assured to only get a new sets of data as needed basis. Here is the actual demo of realtime database update (See video below). As soon as data is changed in database, the LED’s state connected to Raspberry devices instantaneously changes status.
  4. Free- Developers and business owners can create two projects in Firebase for free. This means organization need not to buy premium license during R&D stage. It gives developers and decision makers enough time to learn and evaluate the technology.
  5. Authentication - It comes with a builtin authentication module. Supports gmail, Facebook, Twitter, and basic username and password login support. Integrating this module in your app is easy through their SDK.
  6. Rich API Document - The Firebase SDK is well documented and has lots of example over the web. On our case, we were able to try the SDK for NodeJS. Other Platform supported are IOS, Android, Java, and JS.

As for the Disadvantage

  1. No Data Explorer - This issue is more for developers. The Firebase Database does not provide an online tool to allow developers search for a data inside a node. It has a manual tree like data explorer but becomes complicated or difficult to traverse as dataset goes bigger.
  2. No built-in Authorization - One of Firebase strong point is it’s authentication module. However; it could had been better if it is shipped with a pre-created framework for authorization. To date, developers has to secure data and forms by manually coding the roles for a specific users.

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.

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

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 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.

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.