It’s been a long time since I last used Firestore (Before Firebase acquired by Google), as my work has mostly focused on server-side development. Traditional databases often make more sense in terms of cost and flexibility. However, while working on a recent React Native project, I had the chance to revisit Firestore and refresh my knowledge. Inspired by an official Firestore video, I decided to share some of the rules outlined in the video along with my opinions on Firestore's data structure.

Rule #1: Document have limit

Understanding database limitations is crucial when modeling your data structure. Firestore, like all database systems, has certain limits to prevent exhausting the compute and memory resources. Below are some key limitations you should consider:

• Max 1MB limit per document
  Technically, Firestore allows any data types, but just because you can store an image inside a document doesn’t mean you should. 1MB document should be enough for 99.99% of your use cases.

• Max 20k fields limit in document
  When you modeling the data structure, you have to prevent keep adding new fields in the document.

• Max depth of sub-collections is 100
  Avoid excessively nesting sub-collections in your data structure.

For more details, please check this link: https://firebase.google.com/docs/firestore/quotas#collections_documents_and_fields

Rule #2: You can't retrieve a partial document

Firestore doesn’t allow partial document retrieval. If you need to check a specific field, Firestore will return the entire document, and you’ll need to extract the field yourself.

Fortunately, Firestore charges based on document reads, not size or bandwidth (Talk more in Rule #4 later). However, took this consideration when modeling your data structure, especially when query come from mobile apps, as it may increase battery and data usage.

Rule #3: Queries are shallow

When you query a document, Firestore retrieves the document but not its sub-collections. Keep this in mind while modeling your data structure to avoid unexpected behavior.

Rule #4: You're billed by the number of reads and write your platform

Firestore is charges based on the number of reads and writes rather than the storage size. Optimize your data structure to minimize reads and writes, but don’t over-complicate your code for just saving a few dollars per month, totally not worth for the engineering cost.

Rule #5: Queries find documents in a single collection

Firestore queries can only retrieve documents from a single collection. This limitation means no joins (or groups) are possible, so you’ll need to plan your data modeling accordingly.

Rule #6: Arrays are weird... maybe not now

Firestore is supports arrays, and while there were limitations in the past. However, improvements have make them more reliable for now. You can now use special array operators for manipulation the array. Learn more here: https://firebase.blog/posts/2018/08/better-arrays-in-cloud-firestore