My app requires an online DB sync'ed with a local DB. Will Firestore be prohibitively expensive, by either $ or battery, in the following scenario?

The app is free, and intended to store a time series over a period of months to years. These writes will be frequent and low-data (think temperature/acceleration readings, at a rate of 2 mins or less). I have previously implemented a SQLite <-> Datastore sync, but am considering moving to Firestore to take advantage of it's automatic syncing. However: I don't want the user to be pinging the server ever 3 minutes (battery power) and I'm worried that Firestore may prove prohibitively expensive if each individual write is counted as a write vs being able to batch each 30 mins or so.

The app also needs immediate access to the data (for display), and I'd rather fetch all data from the same place. In other words, if I do use the batch commands in Firestore, will that data be available immediately or will it wait until I close the batch?

1 Answers

0
Adrian Murray On

The only technical question I can see here has to do with how batch writes operate, and more importantly, cost. Simply put, a batch write of 100 writes is the same as writing 100 writes individually. The function is not a way to avoid the write costs of firestore. Same goes for transactions. Same for editing a document (that's a write). If you really want to avoid those costs then you could store the values for the thirty minutes and let the client send the aggregated data in a single document. Though you mentioned you need data to be immediate so I'm not sure that's an option for you. Of course, this would be dependent on what one interprets "immediate" as based off the relative timespan. In my opinion, (I know those aren't really allowed here but it's kind of part of the question) if the data is stored over months/years, 30 minutes is fairly immediate. Either way, batch writes aren't quite the solution I think you're looking for.