Firebase Data Modeling
Chris Esplin
85015

Chris,

This is a really helpful article — thank you for taking the time to write this.

I’ve been working with Firebase for a while now, but architecturally I’m still confused about how often to duplicate data.

Say for example there’s a social networking site with a feed of posts. When a user creates a post, that post is stored in “posts/{postId}”. Given that post now needs to also be viewed by that user’s followers, on that user’s profile, etc…, would you recommend (a) storing all of that post data in all of the locations it needs to be saved (follower feeds, etc…), or (b) storing just the postId to each location and fetching from posts/{postId} when needed? I just don’t know if it’s better to have the actual data in one place and point to it, or duplicate that data in (potentially) thousands/millions of places, then deal with potentially updating data in thousands/millions of places.

Another example, as you show in the “queue” demonstration, is changing a username. If data is duplicated rather than referenced by key, and a user decides to change their username, then wouldn’t every piece of data in the database containing that username need to be updated, as well? That could potentially be in so many places in the database.

Sorry for the long post, but this has just been baffling me as to the best way to go about it when things start getting more complex.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.