If you know your access patterns up front, you can design for a NoSQL database, including the relationships between entities. It requires a different way of thinking about things as you use overloaded keys to create relationships between entities. I'm not too familiar with Firebase, more so with DynamoDB, but the principles still stand. Look into single table design. However, if you have dynamic access patterns - i.e. a user of your application can decide what they want to query, building that against a NoSQL database is generally inefficient and will often require over fetching and filtering in your code, rather than in the database itself. Then an RDBMS like MySQL will generally work better. If you define more about your use case it'd be possible to be more specific