Datastore organization choice

Hello everyone,
I want to make a game in which you can create levels, and share it to the world.

The whole process is time consuming, and I stumbled upon several issues with datastores, but there is one that I think I need people to review it.

I want to keep track of levels the player played. If the player finished it, when he played it, if he liked it or not, …

This can be achieved using 2 different methods:

Prerequisites

Each level has an ID which is very simple: UserId/LevelID. The LevelID starts at “1”, and goes up.
I can build a whole level, its ID would be 955444514/7 (my UserId / The level slot, it is the 7th one)

Method 1

I could simply store, in a dedicated datastore, everything I need to know (when the player played the level, if the latter finished it, if he/she liked, …)

Imagine I played the level 1234/1, the key would be
LevelInformation/955444514/1234/1
It would follow the pattern LevelInformation/UserID/CreatorID/LevelID
I could store it under a table, simple as that.

Problem is that: if a player wants their data to be removed through RTBF requests, I’d need to know every level they liked, which is quite… sad, considering the key setup…

Method 2

I dispose of a save containing two tables:

{
   Order = {},
   LevelData = {}
}

The Order table lets me know the “played” order. If I played level 1234/1 before 1234/2, then the Order table would look like

{"1234/1", "1234/2"}

In terms of key, it would be numerically ascending.

The LevelData table would store data I want. Consider storing the date the player lastly played the level, alongside whether or not the player liked. By keeping the 1234/1 & 1234/2 levels, it would look like:

{
   ["1234/1"] = {tick(), false}, --tick() for time, and false for "did not like level"
   ["1234/2"] = {tick(), true} -- ^
]

Problem with this solution is the amount of elements it will eventually feature.
I calculated by taking an average, I can easily say I can fit 50k elements when considering the 4MB save size limit of datastores.

That would mean users could play 50k levels before I would need to remove some data. I would be able to do that thanks to the Order table, which keeps track of that. However, deletion in that list will be tough considering I would need to shift every element by one index.
I do not exactly know the time complexity of table.remove().

The pro is definitely the fact I can store everything under a single datastore. That being said, I can easily take care of the different RTBF requests I may receive in the future.


What would you recommend me to do? You can of course give me other alternatives I did not think of!