As far as I understand it (and I might be wrong about this), there’s nothing inherently wrong with having large lists, even thousands of items (up to the hard limit of 10,000)…
The issue is more to do with loading those lists unnecessarily, causing slow performance.
For example, if you have a List field directly on the User datatype for ‘likes’, and a user has 9000 likes on that list, then any time you’re loading that User data (for example on a profile page) you’re loading that list of 9000 items (although, as far as I understand, that list is just a list of strings of the unique IDs of the ‘likes’ - not any of the actual Like data, unless you’re referring to the data of the likes).
That means you’re loading a lot of data unnecessarily, slowing down the load speed of the Profile page for no reason.
And if you’re loading a repeating group of 100 Users, and each User has 9000 likes on their like list, that’s 900,000 likes being loaded on the page, for no reason at all, which won’t be good for performance.
So having large lists on datatypes that you’ll be loading a lot for other reasons is a bad idea, and as @mikeloc points out, for most practical purposes, lists of more than 100 (or even a few dozen) are not recommended if they exist on datatypes you’ll be loading a lot.
However, I can’t see any issue with having large lists on datatypes that you won’t be loading unless you need them…
So, an alternative method to consider (one which I use quite a lot - although I’ve never really tested it for performance with very large lists), would be to create a new datatype, just to contain the list.
For example, in your case you could create a datatype called User_Like_List, which has a field for User and a list field for likes.
As you’ll never be loading that datatype unless you’re specifically looking for a User’s likes, there’s no reason why having 10,000 items on that list should ever be an issue, and in theory it should be easier/quicker to access them, than searching the database for likes connected to the User.
If you need more than 10,000 just create another User_Like_list for the User.
You could add the User_like_lists to a list field on the User datatype - that way, even if a User has 100,000 likes, the only thing you’ll have on the User datatype is a list of 10 unique IDs for the User_Like_Lists (which won’t be a problem at all).
If you need to access the likes for a User you can just refer to the User’s Like_Lists each items likes.
Or, you might not store the lists on the User datatype at all - just search for User_Like_lists for the User (which would just return a list of 10 items) then you can access each item’s likes from there.
As I said, I’ve never actually tested this approach with very large lists (only a few hundred to a thousand), so I can’t say for certain how it performs at scale compared to just having individual likes and searching for 100,000 of them from the database.
But, at least on the smaller scale it works well to keep each datatype light, avoiding loading unnecessary data, whilst making it easy to access any of the ‘nested’ data I need in a simple and efficient way.