Reputation: 1003
I'm working on a side project and want to let my users check if their friends have accounts.
Currently I've implemented it like this:
.get()
query on the user database1 for users with that emailThe thing is that any .get
is considered a read operation, even if no data comes back. Their doc.exists
can only be tun after a .get
so a document read is needed to check for existence.
I'm sure I'm overlooking something obvious, what I want to do is in essence to an .exist() like query that does not 'cost' a read.
1: I'm not actually storing emails in firestore but their hashes, and am querying those. Same effect, but it allows me to query a secondary user database that doesn't expose true emails and other data.
2: Not trying to be cheap per se, but if this app turns commercial this would make the billing a nightmare.
Upvotes: 0
Views: 406
Reputation: 138999
According to your comment, you say that you keep the contacts in memory and for each contact (email address), you search in your existing Firestore database for matches.
Free quota exceeded within an hour
It means that you are searching the Firestore database for a huge number of contacts.
The thing is that any .get is considered a read operation, even if no data comes back.
That's correct. According to the official documentation regarding Firestore pricing, it clearly states that:
Minimum charge for queries
There is a minimum charge of one document read for each query that you perform, even if the query returns no results.
So if you have for example 1000 contacts and you query the database for each one of them, even if your queries return no results, you're still charged with 1000 read operations.
I'm sure I'm overlooking something obvious, what I want to do is in essence to an .exist() like query that does not 'cost' a read.
That's not how Firestore works. This means that every query incurs a cost of at least one document read, no matter the results.
1: I'm not actually storing emails in firestore but their hashes, and am querying those. Same effect, but it allows me to query a secondary user database that doesn't expose true emails and other data.
As you already noticed, doesn't matter if you store the actual email address or the corresponding hash, the result is the same.
2: Not trying to be cheap per se, but if this app turns commercial this would make the billing a nightmare.
Try for this feature, Firebase realtime database and believe me, both work very well together in the same project.
Upvotes: 1