2

When using Firestore and subscribing to document updates, it states a limit of 1M concurrent mobile/web connections per database.

https://firebase.google.com/docs/firestore/quotas#realtime_updates

Is that a hard limit (enforced/throttled in code)? Or is it a theoretical limit (like you're safe up to 1M, then things get dicey)? Is it possible to get an uplift?

Trying to understand how to support a large user base without needing to shard the database (which is one of the advantages of Firestore). Even at 5M users, it seems you would start having problems because you'd probably hit times when >20% of those users were on your app simultaneously.

wildcat12
  • 975
  • 6
  • 13

1 Answers1

0

As you already noticed, the maximum size of a single document in Firestore is 1 Megabyte. Trying to store large number of objects (maps) that may exceed this limitation, is generally considered a bad design.

You should reconsider the logic of you app and think at the reson why you need to have more than 1Mib in single a document, rather than each object being their own document. So to be able to use Firestore, you should change the way you are holding the data from within a single documents to a collection. In case of collections, there are no limitations. You can add as many documents as you want. According to the official documentation regarding Cloud Firestore Data model:

Cloud Firestore is optimized for storing large collections of small documents.

IMHO, you should take advantage of this feature.

For details, I recommend you see my answer from this post where I have explained some practices regarding storing data in arrays (documents), maps or collections.

Edit:

Without sharding, I'm affraid it is not an option. So in this case, sharding will work for sure. So in my opinion, that's certainly a reasonable option.

Alex Mamo
  • 130,605
  • 17
  • 163
  • 193
  • Thanks Alex. I was actually talking about the 1,000,000 concurrent mobile/web connections limit. I'm wondering how to support a high number of users, say, 5,000,000+ without sharding the database. Totally agree on designing an architecture that keeps documents fairly small. – wildcat12 May 16 '19 at 13:57
  • Thanks Alex. Well my question was about connection limits and your answer was about document size limits. But your comment about sharding was helpful, so I'll upvote that one :) – wildcat12 May 20 '19 at 22:23
  • Sounds good, accepted your edit. I'm also kind of surprised that's the answer. So much of marketing/documentation during the beta made it seem like you wouldn't have to shard, that everything would just scale horizontally. Firestore said "build for global scale" and specifically with the 1M connections limit, it said "Beta only", implying that after the beta that limit would either be eliminated or raised...then it just quietly became a "GA actually" limit. Has me rethinking our architecture and whether we should move to something else. – wildcat12 May 21 '19 at 20:26