Morning all! Self hosting Keto, we have the following OPL:

class User implements Namespace {}

class Team implements Namespace {
  related: {
    members: User[];
  };

  permits = {
    containsUser: (ctx: Context): boolean => this.related.members.includes(ctx.subject),
  };
}

class Project implements Namespace {
  related: {
    teams: Team[];
  };
  permits = {
    edit: (ctx: Context): boolean =>
      this.related.teams.traverse((team) => team.permits.containsUser(ctx)),
  };
}

I.e.

Project

has (one as it happens) associated

Team

, with a

Team

having many members. And `Team`s can have a lot of members - thousands to tens of thousands. From looking at the queries this leads to Keto running for a check operation for the

edit

permission for a

User

on a

Project

, we found that it runs a SQL query per

User

associated with the team, as part of its expand subject set flow (refs: traverser.go / engine.go) This doesn’t have great scaling characteristics, so I was wondering: • If we’re modelling this correctly - is there a way to model this that would not lead to linear query scaling against team user membership? • Or if not, are there any plans to tune the optimise the performance for cases such as this?

There are plans, but they are further back on the backlog. We can prioritize though based on commercial demand. I think the model you have looks good already, so nothing you could change there to improve the queries.

Thanks @steep-lamp-91158. Just a couple of follow ons if you have time: • Have you got a GitHub reference (or some such) I can link to for the backlogged optimisation task? • I did try using `SubjectSet`s to see if that would improve the SQL characteristics, but without any success in getting it to work ◦ I asked the bot for some help, but alas no joy. Would you expect this to work? (see thread) ◦ Even if it did work, would you expect the performance to be any better? I’m rather guessing that since you suggested that my existing model looked good, it wouldn’t lead to any improvements