We Built an Authorization Engine That the Fortune 100 Bet On(technology.org)
technology.org
We Built an Authorization Engine That the Fortune 100 Bet On
https://www.technology.org/2026/04/30/we-built-an-authorization-engine-that-the-fortune-100-bet-on-heres-what-made-it-different/
2 comments
We've had community members bring this up[0].
While there are a variety of approaches, currently our recommended solution is to use the Watch API[1] to create Leopard-style (matrix) indexes in the client’s database to enable efficient permission filtering using schema and YAML-based index definitions.
We started down the path of building an example watch consumer[2] but both the team and the interested community members were pulled off it for reasons, but not for technical ones.
This FAQ may be helpful to learn more about leopard indexes[3].
0: https://github.com/Permify/permify/issues/2681
1: https://fusionauth.io/permify-docs/api-reference/watch/watch...
2: https://github.com/Permify/indexer
3: http://nil.csail.mit.edu/6.5840/2023/papers/zanzibar-faq.txt
While there are a variety of approaches, currently our recommended solution is to use the Watch API[1] to create Leopard-style (matrix) indexes in the client’s database to enable efficient permission filtering using schema and YAML-based index definitions.
We started down the path of building an example watch consumer[2] but both the team and the interested community members were pulled off it for reasons, but not for technical ones.
This FAQ may be helpful to learn more about leopard indexes[3].
0: https://github.com/Permify/permify/issues/2681
1: https://fusionauth.io/permify-docs/api-reference/watch/watch...
2: https://github.com/Permify/indexer
3: http://nil.csail.mit.edu/6.5840/2023/papers/zanzibar-faq.txt
But the problem that remains is "authorized search" in an efficient way. Asking permify what resources a user can access and then query the app postgres db with "WHERE resource_id IN ( {list}, {with}, {many}, {IDs}, ... )" does not scale well. How to solve this?