I am looking for clarification on how the actions triggered by cloud functions affect the cost of hosting an app with Firebase.
My situation:
I have a cloud function that is triggered when a post is made...that cloud function writes that post to all of the appropriate uid's on the /feed node mentioned below.
I am using Firestore to host a feed/follow system. It is setup with each user having their own feed at the following path
/feed/{uid}/posts
My question is, if a user has 1,000,000 followers...does that translate to 1,000,000 writes in the eyes of Firestore?
Does that mean that single post will cost $1.80 to distribute? Based on the cost of $0.18/100k writes.
I am just trying to see how this will scale with thousands of users posting dozens of posts...those distribution costs seem very expensive at scale for this situation.
EDIT
It looks like it does cost for every read/write in a cloud function base on the following video:
https://www.youtube.com/watch?time_continue=49&v=6NegFl9p_sE&feature=emb_logo
It depends on how you are writing to Firestore, but bottom line is that yes, you get billed for each read/write operation performed to Firestore as mentioned over at their documentation.
Additionally, you get billed per Cloud Function invocation as mentioned here, so you would need to keep this in mind if you want to keep your expenses low.
Hope you find this useful.
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.
I have a large node in Realtime Database that I want to delete everyday using Cloud Functions schedule.
Is there a limit on how much data I can delete using Cloud Functions on Realtime Database? And where can I find the cost for delete?
I've read the billing doc (link) but I'm not sure where it is mentioned about delete cost.
I'll start by adding this link.
Combining the informations in your link and in this one I've added, the answer is: no, you'll not be billed if you just delete data. The important information here is: if you just delete it. You will still be billed if, before you delete it, you download it. In other words, if you get the reference to a node in your code, and then you just perform a remove(ref), you won't be billed.
There is a remote possibility that you can be billed for a huge CPU consumption. This could happen if the node you're deleting is really big, but you can estimate this by testing it out and checking the "Usage" tab in your Firebase console, under the voice "Load". If the load for a testing delete is low, you're good and you won't be billed.
I want to write a scheduler to be triggered once every month to do a particular job that affects all users in a firestore database. What I want to know is, if I have for example one million users compared to having just one user in the database. what is the cost of running that scheduler for one user compared to one million users?
The Firebase documentation states that it cost $0.10 per job per month, but this does not seem to take into account the number of users involved.
So does the pricing of the scheduler change depending on the number users, can someone please clarify this, thanks in advance.
You are using three services, each with their own pricing:
Cloud Task Scheduled, which charges per job.
Cloud Functions, which charges per invocation, and then for the memory/cpu usage for as long as the function is active.
Cloud Firestore, which is charged per read/write operation per document, and for the bandwidth used to read data.
The total you pay is the combination of all these services. I recommend putting all your info in the Google Cloud Pricing Calculator to get an estimate of the cost, and (more importantly) in the factors that determine that cost.
As explained in the official documentation here, of Cloud Scheduler - that it seems to be the one you will be using:
Cloud Scheduler pricing is based exclusively on the job. A Cloud Scheduler job defines a single activity scheduled to run at a frequency provided in the definition.
The number of users is not considered as well directly in the Cloud Functions pricing, as its per invocations of the function. To summarize, it doesn't matter the number of users, but actually the number of jobs and invocations, that you will need to control, so you can calculate the real cost you will have.
Hey so with my current feed database design, I am using Redis for the cache for super-fast reads, which are routed through my Google Cloud Functions. The Redis database handles all post data and timeline updates, which is great and all, but I forgot one of the most considerable caveats to this. Firebase Firestore only permits one document write per second, meaning that if I have a document that stores the post data (post_id, user_id, content, like_count), the like_count would be impossible to track with the possibility for many likes per second. Does anyone have any solutions to this?
You can shard your counter among multiple documents and query them in aggregate as needed.
You can also try Cloud Tasks queue to smooth out the write frequency. It will add considerable complexity to the system, but is really the only genericized way in GCP to manage the rate of some work. This might not work out the way you need, however.
If you use Cloud Tasks, your task will need to be configured with a rate limit, and it will have to deliver the document data to write to yet another function or other HTTP endpoint that will perform the write.
I know that I could implement a counter in my application but using an api would still be a cleaner solution - if one exists?
Basically, Firestore has Spark free tier limits (think 50,000 reads/day) that I don't want to exceed. So whenever my app was going to do firestore reads, I would like a way to simply ask firestore whether I'm over a certain number.
I'm also reading that Google intentionally got rid of Firebase spending limits.. which seems really sketchy... Impossible to set the Cloud Firebase daily spending limit
There is no such API as part of Firebase. The ways to monitor usage are documented here, but none of them is an API.
You might be able to get some data through the Cloud Monitoring API. But this API isn't made for client-side access though, so you'll have to wrap it yourself.
A final alternative would be to look at a service like https://firerun.io/ who automate a lot of this.