As I understand his problem and imagine the solution, my suggestion would use purely glide computed column functionality, so there would be no need to use any google formulas or scripting to accomplish any of it. Because of that it would make no difference if an app is Glide Table or Google Sheet based.
As for speed, I haven’t sat and timed anything real extensively. My primary app is over 2 years old and was built prior to Glide Tables existing. Some parts are slow, but I believe it’s self inflicted due to how many calculations I’m performing, but 95% of the functionality is now using glide computed columns. I would have to believe that Glide Tables have some speed advantages due to the lack of a need for glide to sync with a google sheet, but as I see it, google sheet based apps still have the database duplicated on glide servers as glide tables. Since an app communicates with the database on glide servers I wouldn’t imagine that there would be any major speed issues unless there is a need to resync large sets of data between google and glide, or if you have formulas or scripts exclusively within the google sheet, then there will definitely be lag waiting for data to sync to the google sheet, calculate, then make the return trip to glide before being pushed back out to the app.
Think of it this way…with a google sheet based app, there are up to 3 copies of the data (google sheet, glide db, and local app cache). With a google sheet based app, there is the additional path that data has to travel to sync, but I think it’s mostly only noticeable when the google sheet is doing additional work. The app synchronizes with the glide servers exclusively and the glide servers synchronize with the google sheet, so the app won’t know any different either way. Glide Tables and/or USC columns will only ever reside on Glide servers and the local app cache. The only potential problem I could maybe see with google sheets is if there is heavy data entry or changes that would cause large amounts of data to sync between glide and google often. I still think a sheet based app that primarily uses glide tables would give you the best scalable performance while allowing for the potential to switch to using the google sheet if some of your data needs to access some functionality that’s only available with a google sheet.
@Rogelio I’m imagining something along the lines of how the demo apps in this thread build a joined list, which could be saved to a single row and later split again for any relations. @Roldy has a good example where he actually saves and recalls the saved selections. I’m not sure if it would give you exactly what you need, but if it works, it would potentially eliminate the need for several additional rows. You may still need a separate table, but it would have only one row per user/tour. If possible, you could even place the joined list in the user profile row and eliminate the extra table altogether.