Disclosure: I'm a cofounder of Authzed and one of the creators of SpiceDB, the primary strawman for graph-based authorization used in this article. I don't bel

Disclosure: I'm a cofounder of Authzed and one of the creators of SpiceDB, the primary strawman for graph-based authorization used in this article. I don't believe that any of the data being represented in this article is ubiquitously true, though it might be true for the users self-select into adopting Permit. There is no one sized fits all solution for authorization and we see folks self-selecting in the other direction, so I'd like to offer that take. >Despite their advantages, deploying a Zanzibar-based graph invariably introduces a sizable and complex system into your cloud environment, often necessitating reliance on a hosted service. This dependency can instigate latency concerns and further scaling challenges. There are plenty of happy SpiceDB open source users and on-premise Authzed customers that have no need for a hosted service. Using a hosted service doesn't mean adding additional latency. For example, Authzed's services deploy to the same cloud datacenters as your applications, so the latency is no different from your application connecting anything else not running on the same machine. We've helped folks migrate away from policy-based systems because having unbounded computation eventually leads to the inability to make guarantees about performance. It's easy for developers to over time add more and more logic to the sets of policies that are critical until they become too slow for some of the services that depend on them. Lest we also not forget the complexity and scaling challenges a system that has to keep data in policy engines synchronized. --- I'd also like to point out a few things from the comparison table: Nature of Access Control: As stated in this article, SpiceDB supports ABAC and can model more than just RBAC and ABAC. Reverse Indices: This is a big deal. What systems can you build without asking "Who are all the people with access to this?" and "What are all the things this person can access?". Latency & Performance: SpiceDB guarantees runtime performance no matter the scale and complexity and operates on a consistent view of data while policy engines typically end up working on stale data. Unfortunately, this is comparing apples to oranges because the two systems are generating two different qualities of decision. Deployment at Edge: SpiceDB and Zanzibar were designed to run at a global scale. You can run a SpiceDB cluster at each edge that share a global backing relationship store (Spanner or CockroachDB). I'm not familiar with any policy engines that were designed while considering where the data lives -- as such they require additional systems to best-effort synchronize data to those engines. Ease of Updates: Honestly, this is purely opinion. It's quite simple to exhaustively test SpiceDB schemas to assert correctness -- play.authzed.com even generates them for you. I think it's more difficult testing turing-complete policies. Ecosystem: "Emerging ecosystem" is sold in the article as an anti-feature when it is a feature depending on your own goals; for something to be emerging and gaining traction, it has to be seen as an improvement over existing systems. Despite calling ReBAC systems "emerging", the article does describe SpiceDB itself as mature, though.