It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
The short version: if you can't articulate, right here and right now, why you need to use a non-relational database, you should use a relational database.
In your specific case, you're already talking about slicing movie data multiple ways and applying award information. That's clearly a join between two tables. You have relational data, and if you try to shoehorn it into a non-relational schema you will eventually regret it.
If you want to represent certain data as documents (I'm not sure user watchlists are the best example here, since they still constitute relationships between users and movies) then look into Postgres' JSON functionality which allows you to blend relational and document strategies quite effectively.
The short version: if you can't articulate, right here and right now, why you need to use a non-relational database, you should use a relational database.
In your specific case, you're already talking about slicing movie data multiple ways and applying award information. That's clearly a join between two tables. You have relational data, and if you try to shoehorn it into a non-relational schema you will eventually regret it.
If you want to represent certain data as documents (I'm not sure user watchlists are the best example here, since they still constitute relationships between users and movies) then look into Postgres' JSON functionality which allows you to blend relational and document strategies quite effectively.
You are right, I can articulate exactly why a relational DB is suitable for my needs, but not the other way around. Clear signal :)
I was just wondering if I was missing something. Thanks for clarifying, and I'll def look into Postgres's JSON functionality.