This message was deleted.

Hi @Andrii Kasparevych - these are most likely (>95%) issues with OPA not OPAL. As OPA is running with the OPAL-client container. OPA is known to bloat loaded data in memory - as it loads it into objects; You can improve that by changing the data schema and policy structure. And yes high volume of data, and inefficient structure will lead to bad performance. A few suggestions to what to try next: 1. Validate that the issue is OPA and not OPAL - you can do so by one of: a. check which process is the one with the extensive memory consumption within the container b. loading the data manually into OPA regardless of OPAL c. Running the OPA agent standalone to the client 2. Check if you actually need all the data - most often the data needed for authorization is a very small subset (often just ids and their relationships) - you can save a lot of space by minimizing the data - once you decide on the subset you actually need; you can do so on the fly using a custom data fetcher , or by adding an API service to perform the transformation. 3. Increase the container / machine resource limits (memory / CPU 4. If you do need all of the data - consider sharding it between multiple OPA agents

thanks @Or Weis, that's what I guessed as well about OPA being the guilty one. Gonna run some more tests in isolation and reach out to them. For the production use the case will be different, but I wanted to check how it would perform in a scenario like this here.

Looking at the playground example - You can save a lot by dropping (or moving to a separate hash map) the

entityType

and

role

fields you are not using, and are probably repeating a lot. Keep #4 - sharding in mind - OPAL can help there by doing topic based sharding between OPA agents. And you can do either routing before the OPA agents, or chaining between them with http.send