Is saving real-time location in real-time firebase database too frequent?

I am making a road game app for the company. This requires real-time location. I am using the Realtime Database to manage all data. Everything is fine, just small worries about storing location, location history, and frequency of updating it. Given, that thousands of people won't be using it at once I don't think it should be a problem, but wanted to ask. Active users would be measured in tens not even a hundred people will use it at once. Currently, I update the user location on DB only if the user has moved more than 10m from previous stored location. So that's when also I save location history as well. Given that they might be driving most of the game that can last up to 3 hours with 30 people this will end up in a lot of writes. However, most likely won't use the app nonstop.

I think the GPS refresh is at 1HZ. Here comes my concern. Is that too frequent? Let's say 30 users write location once per second. On top of that, some game activities (not nearly that much). Solution (if needed) I could bundle up let's say 10 records and update every 10 seconds. But this might lead to data loss if the user closes the app before I upload, not critical.

I think over 3h session it's going to be a few tens of mb data in location history. so in the worst case, that's 60 * 60 * 3 = 10800 writes of location per user * maybe 30 people and I get 324000 writes of location per session (Very unlikely). Then also this is monitored so reading it as well as it updates. Will this overload the server? Data transferred isn't that much all together that structure for location history is like this. The rest of the data is on different branches of db, do I not listen for location history when I don't need it?

  session_id:{
    user_id:{
      1707554820567: {
        lat: 00.0000000
        lng: 00.0000000
      }
    }
  }
}

Solution

When it comes to writing data very frequently in the Realtime Database, please note there is a limitation that refers to the write rate. So you can write up to 1,000 writes/second on a single database instance. So as long as you stay below this limitation, I cannot see any other problems.

If you think that you can get over this limitation, then you should consider sharding the data by creating multiple Realtime Database instances. So in this way, you'll be able to perform a number of writes that is equal to (1,000 * number of databases)/second.