struggling to structure data in Firestore for a new social app, any tips for a noob?

Hello Sakura Sato,

i'm totally stuck on how to properly structure my data in Firestore, especially with relationships between users, posts, and comments.

It's a common hurdle when transitioning to NoSQL. For a social app like a mini-Twitter, optimizing your Firestore data modeling for read performance is crucial. Regarding embedding user data, you should embed only the minimal, frequently accessed user details (e.g., `userId`, `username`, `profilePicUrl`) directly into posts and comments. This significantly reduces the number of reads needed to display a feed or a comment section, as you won't need to fetch the user document separately for each item. For complete user profiles or sensitive data, always use a reference to the main `users` collection. This strategy balances read efficiency with data integrity, especially since updates to embedded data would require multiple writes. To efficiently query for a user's feed or all comments on a post, consider these approaches: For comments, storing them as a subcollection under each post (e.g., `posts/{postId}/comments/{commentId}`) is highly effective. You can then fetch all comments for a specific post with a single query to that subcollection. For user feeds, a common pattern for scalability is "fan-out on write." This involves maintaining a `feed` subcollection for each user. When a user creates a post, you write it to their own `posts` collection and then duplicate that post document into the `feed` subcollection of all their followers. While this increases write operations, it makes reading a user's feed extremely fast, as it's just fetching documents from a single, pre-populated collection. Alternatively, for smaller scale or less active feeds, you could query the top-level `posts` collection and filter by the `authorId` of followed users, but this can become read-intensive. When dealing with complex relationships or querying across subcollections, remember to leverage `collection group queries` for efficiency. The general rule of thumb for Firestore is to embrace denormalization for read optimization; duplicate data strategically to minimize reads, which are typically the most frequent and impactful operations on your budget and performance. Have you started implementing any specific collection structures yet?