Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
We are building a chat app, one-to-one chatting is the main purpose of the app so for now, messaging speed is our first priority. We need a backend solution and we were initially planning to use Firebase realtime database. But then Firestore came to existence, from there onwards we saw a lot of recommendations for Firestore over Realtime database from the Firebase team.
We have used both Realtime Database and Firestore so we are pretty aware of the capabilities and querying powers of both. For our use case in terms of features, any of them are fine. But as I told before our main concern is messaging speed. So which one is more realtime?
So which one is more real-time?
I don't think one is more real-time than another.
But then Firestore came to existence, from there onwards we saw a lot of recommendations for Firestore
That's right, Firestore has some new features over Firebase Realtime Database, that's why is named "the new flagship". The query performance depends on the number of items you request and not on the number of items you request them from. So every time you think to get data, get it in such proportion to maintain the speed that you were talking about. As the guys from the Firebase team say, Cloud Firestore has a performance guarantee, there are no slow queries, so the time it takes your app to retrieve data depends on only on the amount of data you retrieve and not on the amount of data you have on Firebase servers. In other words, it doesn't matter if you have one thousand, one million, or even one billion documents within a single collection, retrieving for instance 15 of them, will always take the same amount of time.
This performance comes with some constraints and for that, I recommend you take a look at all sections within the official document regarding getting data in Cloud Firestore. That's the reason why Firestore uses those constraints, is due to the fact that is mandatory to maintain this performance guarantee. But from my experience, there is no "SQL" query that cannot be translated in a way or another in Cloud Firestore.
So remember, it really does not matter if you request a single document out of a 10 or one item out of 100.000 or 100.000.000.000, the result will come in the exact amount of time. Here I took as an example one document. So regarding speed, requesting one document out of 100 million will be faster than requesting 10 items out of the same 100 million. So the number of documents in the collection has no effect on the query performance.
This is about Cloud Firestore but there two main resources that I recommend you read before using one or another:
https://firebase.google.com/docs/database/rtdb-vs-firestore
https://firebase.googleblog.com/2017/10/cloud-firestore-for-rtdb-developers.html
So check the price models for each one of them. But IMHO, both Cloud Firestore and Firebase Realtime database work extremely fine together.
In my opinion calculation is simple. Realtime database 10 000 M chat messages data transfer = $490. Firestore 5 000 M reads = $3000 and 5 000 M writes $9000 = $12000. So the cheapest way is to use realtime database and because of $5/GB stored you need each few weeks/months rewrite messages to firestore. For chat app like discord where you have conversation shared with many users the best way is to set a server witch different database like Cassandra.
Related
i've been searching for what is the concurrent users limit for the cloud firestore spark plan but couldn't find it.
https://firebase.google.com/docs/firestore/quotas
It did said 1.000.000 concurrent users limit, but did not mention whether it is for the spark plan or the blaze plan. I've also tried searching answer elswhere, but did not find it answered specifically (with a source).
Help would be appreciated, thank you.
Per the Cloud Firestore pricing information (which Firebase uses):
When you use Firestore, you are charged for the following:
The number of documents you read, write, and delete.
The amount of storage that your database uses, including overhead for metadata and indexes.
The amount of network bandwidth that you use.
There is also no mention of any connection limits on Firebase's pricing page or the quotas documentation that you linked.
Unlike the Realtime Database, Cloud Firestore does not charge on a per-connection basis.
This video series also covers the ins and outs of Firebase products and is well worth sitting through.
Think of Cloud Firestore like a folder on your computer, which can contain thousands of little text files, similar to how documents in Cloud Firestore are stored. Users can update them with little chance of collision and grabbing a single document file would only require feeding 1s and 0s back to the requestor. This is why you are charged for network bandwidth rather than by individual connection.
In comparison, the RTDB was similar to one large JSON text file, with many people all trying to update it at once. Because parsing this text file on the server side was required to read and write data from it, it required compute resources to be able to do so. For this reason (among others), the number of connections the RTDB manager processes handled on behalf of spark plans were rate-limited to prevent abuse.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
Is there any situation where it makes sense to use both realtime and firestore in conjunction? What situations lend themselves more favorably to firebase realtime vs firestore, or a combination? I keep reading about horror stories of people getting hit with huge costs is there anyway to test before hand.
For context I am looking to work with an auction based market place of over 50,000 products. The idea is to be able to filter those products as needed, create, modify and delete bids for those products, favorite items and retrieve Users bids. From what I was reading the general suggestion (to keep cost low) for market places using firebase seems to suggest storing products in realtime db and the user objects, sales etc. in firestore. Kinds of queries I will need are find products with the lowest/highest bids, most favorited items, as well as fetching users current and purchases.
When would it be optimal to store in realtime vs firestore, from a cost perspective?
My current logic is to store the product objects in realtime since they will be referenced more frequently. Alternatively I am thinking it makes sense to store the user info, their bids, and purchases in one document in a firestore as that would incur just one read cost, and for a highly active user could result in a large amount of data to be transferred. Where I am confused comes with things like viewing the previous sales of a given product vs getting a user's previous sales, should sales be stored in realtime (as their own object or embedded in the product object) or firestore (embedded in the User doc) or both?
Looking at your app that you plan to make, let have a short talk regarding it.
A bidding app, first someone wants to sell their stuff so they post it in your app. Then every single user of your app may see it start bidding on it. Now as I don't know how your app is going to work but here's my assumption you will store the data of bidders and the bids they make in firebase realtime database.
This will involve lots of read, write operations. Now Firestore does offer you 20K operations/day, but if you cross the limit it will barely cost you $0.18/100K writes and $0.06/100K reads. Now the choice entirely depends on scale of your app. If your app has large number of audience, go for Realtime-Database. You can download upto 10GB of data per month for free and a dollar per GB beyond that. But this has a catch, if you stick to the spark plan, you can have only 100 simultaneous connections to the database so I doubt the performance if you have large number of users. It can go upto 200K using Blaze plan and that too per database. So if you create another database you will have more. I will personally suggest create multiple databases as per the region or any parameter to spread the traffic. [Again it's upto how many people use your app]
In my opinion, you should use the Firebase Realtime database your app. [Make sure you utilize the firebase storage as well for storing large photos of the things on sale].
Lastly, use firestore when you have less number of operations but are larger in size. Use firebase realtime database when you have many small tasks like updating the highest bid value or number of users currently bidding for a particular thing, use Realtime DB.
In my opinion, go for realtime database. I too use it for some game stuff like to store user stats and update it as the user progresses. This involves lots of read/write/update/delete operations so I stick with realtime-database.
When to use Firestore along with the real-time database?
As you have mentioned user profile, I will suggest use Firestore to store those credentials. Because user's won't generally update their profile so this won't cost much writes. Also the bidders would be much interest in bidding rather than watching others profiles. So even if if a few users check other's profile. This won't cost you much reads. But even if your app is designed in such a way that bidder must check seller's profile once, then firestore will definitely help you reduce usage of realtime database's [GB Downloaded] quota.
Every time someone queries data from your realtime database, you consume some part of the 10 GB of free download limit.
Also as I have mentioned the simultaneous connections to the database, if you host user profile data in Firestore then firestore will take care of profile visits so that bidders get faster response from your application. Just make sure you utilise all the free quotas from firebase storage, firestore and the realtime database and make sure your app is designed in such a way that it spreads traffic evenly between all services. Use the cloud functions on your back-end, and don't make your application [.apk] too heavy on client side as the app needs a lot to code.
So the conclusion, use firestore to store data which won't be accessed frequently like the user credentials and whatever stuff they have on sell. Use realtime database to store bidding data. Oh and yes, if you also want to store some stats like how many purchases has someone made or some information that changes too frequently put that in firebase realtime database. You can simply create a child node users/${username} and keep the frequent stuff in realtime database. This won't cost you much storage but take of that download limit. Shouldn't be expensive much especially talking of your app is going to address 50000 products XD.
I am looking to work with an auction based market place of over 50,000 products.
If you have comparatively less number of users, realtime database is sufficient but who knows when there may be a huge rise in your app users. So it's better to spread the data in both Firestore and Real-time database as mentioned above.
Just a caution: This is what I faced, then searched over stackoverflow and found this. Firestore counts READS even if you are just scrolling over the data tab in firestore. So make sure you don't just get surfing over there. I made 2 writes and was just looking at how the data is being stored and I already got 27 reads ...
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I am developing android and IOS app with web backend admin support for an organisation oriented employee, tasks and issue management system. issues and the task will be posted by any public people and issue will be addressed and solved by the organization people.
my app will have dynamic keyword filtering over the new issue posting and an algorithm will keep running to identify the issue categories dynamically from the issues being posted.
my app or the search result and filters should be fast in retrieving the data and it should not affect my application performance. I didn't know which one is good to use for a case like this.
I use the Realtime database for an large iOS app that contains users, jobs for users, favourites, messages etc. So I need the database to show results in realtime as well as being reliable.
The best features for a big app like the one I have built are the
offline capabilities
If the user goes offline, the database is still responsive and persists data to the disk which resynchronises when connection is established.
Data synchronization
All of my users on the app can see changes happening instantly such as notifications and messages, job updates etc. It's reliable and stops any overlapping potential risk.
https://firebase.google.com/docs/database/
Additionally, it sounds like you will benefit from the easy JSON structure that Firebase Realtime database offers to build categories etc.
I use a lot of filters in my iOS app and the calls to the database return results almost instantly given a connection is established; its very flexible.
In terms of reliability
Cloud Firestore is currently in beta. Stability in a beta product is not always the same as that of a fully launched product, where as Realtime Database is a mature product.
Use Fire-Base Realtime database if your apps are not going to serve more than 1000 people.
Because Fire-base Realtime doesn't perform much complex and fast queries like Fire-Base FireStore. And you can not upgrade your app if your app is based on RealTime database.
FireStore has more features that Realtime database.
You can go and check the difference between both of them:-
https://firebase.google.com/docs/database/rtdb-vs-firestore
I would like to use Firebase Firestore for my next project but I need some help understanding the limitations of what is possible with Firestore queries.
Basically, I would like to perform queries over collections with large amounts of documents but upon doing research I have come across conflicting information.
This video (from the Firebase team): https://youtu.be/W3xIOQu0h1w?t=11m50s states that you can perform a query over a collection with "billions" of documents and maintain the same level of performance compared to a query over a collection with a few documents.
Then, I came across this github issue where the poster states that queries are taking too long and demand alot from the system. A member of the Firebase team answers by stating that performing a query over a collection containing 35k documents is beyond the "performance envelope".
So can someone point me in the right direction concerning Firestore queries and its limitations.
Please let me know if I was not clear in any part of this post.
That GitHub issue you linked to is specifically talking about offline searches. This means the Firestore backend service is not available, so the search is performed on the client. This is a very different situation than when the client is online and the service can perform the query in a massively scalable way. (Client apps are never massively scalable.)
Google just released Cloud Firestore, their new Document Database for apps.
I have been reading the documentation but I don't see a lot of differences between Firestore and Firebase DB.
The main point is that Firestore uses documents and collections which allow the easy use of querying compared to Firebase, which is a traditional noSQL database with a JSON base.
I would like to know a bit more about their differences, or usages, or whether Firestore just came to replace Firebase DB?
I wrote an entire blog post all about this very question, and I recommend you check it out (or the official documentation) for a more complete answer.
But if you want the quick(-ish) summary, here it is:
Better querying and more structured data -- While the Realtime Database is just a giant JSON tree, Cloud Firestore is a little more structured. All your data consists of documents (which are basically key-value stores) and collections (which are collections of documents). Documents will also frequently point to subcollections, which contain other documents, which themselves can contain other documents, and so on.
This structured data helps you out in two ways. First, all queries are shallow, meaning that you can request a document without grabbing all the data underneath. This means you can keep your data stored hierarchically in a way that makes more sense to you without having to worry about keeping your database shallow. Second, you have more powerful queries. For instance, you can now query across multiple fields without having to create those "combo" fields that combine (and denormalize) data from other parts of your database. In some cases, Cloud Firestore will just run those queries directly, and in other cases, it will automatically create and maintain indexes for you.
Designed to Scale -- Cloud Firestore will be able to scale better than the Realtime Database. It's important to note that your queries scale to the size of your result set, not your data set. So searching will remain fast no matter how large your data set might become.
Easier manual fetching of data -- Like the Realtime Database, you can set up listeners in Cloud Firestore to stream in changes in real-time. But if you don't want that kind of behavior, and just want a simple "fetch my data" call, Cloud Firestore has that as well, and it's built in as a primary use case. (They're much better than the once calls in Realtime Database-land)
Multi region support -- This basically means more reliability, as your data is shared across multiple data centers at once. But you still have strong consistency, meaning you can always make a query and be assured that you're getting the latest version of your data.
Different pricing model -- While the Realtime Database primarily charges based on storage or network bandwidth, Cloud Firestore primarily charges based on the number of operations you perform. Will this be better, or worse? It depends on your app.
For powering a news app, turn-based multiplayer game, or something like your own version of Stack Overflow, Cloud Firestore will probably look pretty favorable from a pricing standpoint. For something like a real-time group drawing app where you're sending across multiple updates a second to multiple people, it probably will be more expensive than the Realtime Database.
Why you still might want the to use the Realtime Database -- It comes down to a few reasons.
That whole "it'll probably be cheaper for apps that make lots of frequent updates" thing I mentioned previously,
It's been around for a long time and has been battle tested by thousands of apps,
It's got better latency and when you need something with reliably low latency for a real-timey feel, the Realtime Database might work better.
For most new apps, we recommend you check out Cloud Firestore. But if you have an app that's already on the Realtime Database, I don't really recommend switching just for the sake of switching, unless you have a compelling reason to do so.
Reasons to choose Cloud Firestore over Realtime Database
It is an improved version
Firebase database was enough for basic applications. But it was not powerful enough to handle complex requirements. That is why Cloud Firestore is introduced. Here are some major changes.
The basic file structure is improved.
Offline support for the web client.
Supports more advanced querying.
Write and transaction operations are atomic.
Reliability and performance improvements
Scaling will be automatic.
Will be more secure.
Pricing
In Cloud Firestore, rates have lowered even though it charges primarily on operations performed in your database along with bandwidth and storage. You can set a daily spending limit too. Here is the complete details about billing.
Future plans of Google
When they discovered the flaws with Real-time Database, they created another product rather than improving the old one. Even though there are no reliable details revealing their current standings on Real-time Database, it is the time to start thinking that it is likely to be abandoned.
Suggest link from google as well :
Firebase Real-time Database vs FireStore
Extracted from google docs, a small sumamry here:
FireBase Real Time DB is JSON based NO SQL DB, meant for mobile apps, regional, and used typically to store and sync data between users/devices in realtime / extremely low latency.
FireStore is JSON 'like' NOSQL DB meant for high concurrency, global, easily auto scaling persistence, designed for any clients (not only mobile apps) with typical use cases such as asset tracking, real time analytics, building retail product catalogs, social user profile, gaming leaderboards, chat based applications etc.
Cloud Firestore is Firebase's database for mobile app
development. It builds on the successes of the Realtime Database with
a new, more intuitive data model. Cloud Firestore also features
richer, faster queries and scales further than the Realtime Database.
Realtime Database is Firebase's original database. It's an efficient,
low-latency solution for mobile apps that require synced states
across clients in realtime.
To choose between Firebase Realtime database and Cloud firestore based on your application requirements, read official documentation here.