liking/disliking a post will waste 1 write operation(there is 600k write operations in the pay-as-you go tier).

The free tier (Spark plan) includes 20k writes per day (roughly 600k per month), and after that it will cost approximately $0.18 per 100k writes per month depending on your region Writes Pricing.

Personally, I wouldn't worry too much about the cost of writes in this scenario because if you have enough users on your app to be making 600k likes in a month, then your app (hopefully) has some revenue coming in.

The main issue is that a single Firestore document can only handle 1 write per second (can exceed in short term bursts). This is only an issue for you if you're storing all of those likes on a single document, which I assume you are as it makes sense to reduce reads. As Frank mentioned, to get around this issue you can look into distributed counters here.

Another option as you mentioned is to store likes in RTDB. RTDB and Firestore work well together, as long as you're properly managing the data in both places. If you choose to store likes in RTDB beware of the following which may be relevant for your use case:

• RTDB can only have 100 concurrent connections on the Spark plan, and 200k on the Blaze plan. To scale past that (on the Blaze plan) you'll need to shard your data across multiple databases

• A single RTDB database has a current limit of 1k writes per second

• You can't perform batch writes across multiple Firebase services. For example, if you need to update a Firestore document at the same time as write to RTDB and want to make sure they succeed or fail as a group

You won't find a definite "yes" or "no" to your question. I've seen it implemented both ways, and they both work equally as well.

As Frank mentioned, you should look here Firestore vs RTDB to pick which is best for you