I've seen the sentiment in this article pop up in a few places, which I'd summarize as: Policy languages like OPA and Cedar are fast to evaluate and simple to write, so you should use it for all of your authorization needs.

But policy engines are only really fast and simple if they already have all of the data they need at evaluation time.

If you look at the examples in the Cedar playground[0], they require you to provide a list of "entities" to Cedar at eval-time. These entities are some (potentially large) chunk of your application's data. And while the policy evaluation over that data may be fast, the round trip to your database is probably not. And then you start to think about caching, data consistency, and so on, and suddenly you're thinking about a lot of the problems that Zanzibar was designed to address (but you're on your own to build it out).

IMO policy engines are best suited for ambient request data: things you already know about a request because of a session, a route, or a network path, and policies that make sense to manage on the same lifecycle as your application.

Disclaimer: I work on SpiceDB[1], a Zanzibar implementation, but I do also like policy engines.

[0]: https://www.cedarpolicy.com/en/playground

[1]: https://github.com/authzed/spicedb