Handling feed and feed subscriptions with document database

I have a data feed that contains channels that users can subscribe to. It's similar to Facebook or LinkedIn where each channel is a topic and users can subscribe to as many channels as they like and when they do, content posted to that channel appear in user's feed. The best design I've come up with in handling this scenario is still with the good old relational database because with just three simple tables -- Channels, Content and Subscriptions -- and one join, it's possible to get a user's feed. The best part about this is that it seems pretty efficient and no duplicate data whatsoever. I've been thinking about implementing this using a document database but I have not been able to figure out an equally simple and efficient design. Even though "joins" can create performance issues in relational databases, in this scenario the single join really seems to help create a simple and efficient solution. Has anyone implemented a feed with a document database backend? I especially think about what happens when the number of subscribers to a channel reaches millions e.g. say 2 million subscribers to sports channel. In a document database scenario, there always seems to be duplicated data and when the numbers hit millions, a document database solution just doesn't seem appropriate. I'd love to hear comments and suggestions on this. P.S. I remember reading an article about Facebook using a relational database for their feed and it just seems to make sense. As I understand it, they addressed performance issues as the numbers grew by adding additional layers of memory based databases in front of the relational database. I'd love to hear any insights into how these hyperscale platforms handle things.