Hi I wanted to know can we start with file based policies and store principal policies in the database? Also on that would cerbos scale well if I have multiple principal policies for each user? My objective is to make dynamic policies where admin can assign different permissions to each user in the system

Cerbos doesn't support "merging" two data stores in this way. You could consider (something like) automating the injection of policies from file into your database store via some CI mechanism, and then handle the dynamic policies separately. Generally speaking, principal policies are a special case (they override permissions for a principal with a given ID). If you wanted to act solely on principal IDs rather than roles as per more traditional RBAC+, then maintaining a set of principal policies (1 mapped per principal) and updating them via the admin API might well be the way to go. Question: would updating a rule for a role not be viable approach, rather than a rule for a principal ID? From a scalability standpoint, the short answer is: it should be absolutely fine (the PDP is written with performance and efficiency as a primary concern). The longer answer: the considerations would be the number of unique policies and the frequency of updates. If a human operator were updating policies on an ad-hoc basis, this is negligible. Even if there were many unique policies, Cerbos tries to maintain and continually prune an ephemeral cache of recently-used policies, so PDP instances shouldn't be heavily burdened from a memory standpoint. Even in the extreme case of many concurrent requests for a high range of unique policies; providing the PDP has access to enough memory, it should be absolutely fine.

@Sam Lock (Cerbos) Thanks for explaining in detail. I guess having a init process in CI would be the way to go for creating the policies, and yes policies would be updated by human operator using admin API so I guess I have an answer for the performance. Thanks for answering this in details!