Good reading on how to structure Firebase data

I’m thinking about data models and how best to structure things, because discovering that one’s code breaks with more than a couple users is no fun.

If you haven’t already read it, this is interesting:

Not directly about Thunkable, but if you’re putting data in Firebase, definitely relevant!

I’m not a database expert, but I’ve spent just enough time with relational databases that some of my instincts are just /wrong/. I’d not have thought to do the last example because it feels like storing the data twice, but looking at it, I’m like “oh yeah, that would be so much easier to access!”


I like the index of groups idea presented on that site. I found that structuring Firebase around a User ID (generated at Sign Up) kept all data separate and prevented the problem they describe of downloading extraneous data.


I similarly have user data under a user ID. I do definitely need an index. Not addressed (more to learn!) is how to work the permissions in this situation.


When you use the Firebase blocks, basic permissioning is built in. On the app side anyway, you still need to set your rules.

The blocks send the uid along as an authenticated call and allows you to lock down buckets and let only the corresponding user access the data.

This locks down everything from brc/userID so no other user can see it.

@jared , yes thanks, I understood that, but it may be useful for someone else! (And I apologize, I haven’t watched the video yet - maybe you answered it there. My laptop is having sound issues.)

What I was saying above was that if in addition to a /users/ bucket I also needed a /groups/ bucket with structure /groups/groupA/members/(list of members) that I was less sure how to lock those permissions down. (Let’s suppose we let members join groups themselves. I’m thinking it’s just some clever wildcard use to make sure they’re only adding themselves, but I haven’t worked it out or found a really good example of it – yet.