Core differences between Zanzibar based solutions (Keto, OpenFGA, SpiceDB)

General Aspects

	Ory/Keto	OpenFGA	SpiceDB	Permify
Zanzibar Paper Faithfulness	Medium	High	Super High	High
Scalability	Medium	Medium	High	High
Consistency & Cache	No Zookies & Distributed Cache	No Zookies & Distributed Cache	Supported	Supported
Dev UX	Average	Average	High	High

	Ory/Keto	OpenFGA	SpiceDB	Permify
Disk and DB-Based Storage	✅	✅	✅	✅
Read API	✅	✅	✅	✅
Expand API	✅	✅	✅	✅
Watch API	✅	✅	✅	✅
RBAC	✅	✅	✅	✅
ReBAC	✅	✅	✅	✅
ABAC	⛔	🟡	✅	✅
Data Filtering	⛔	✅	✅	✅
Multi Tenancy	⛔	✅	⛔	✅
Hotspot Caching	⛔	⛔	✅	⛔
Consistent Hashring	⛔	⛔	✅	✅
Testing & Validation	⛔	🟡	✅	✅
Logging & Tracing	🟡	✅	✅	✅
MVCC & Performance	⛔	⛔	✅	✅
Governance & Ops Dashboard	⛔	⛔	⛔	✅
Partial Schema Update	⛔	⛔	⛔	✅
Schema Staging	⛔	⛔	⛔	✅
Relationship Bundles	⛔	⛔	⛔	✅

Implementation & Modeling

Zanzibar data model relies on relationships so every permissions are set of relations. Because of that relation based use cases (ownership, parent-child, hierarchies & organizations, user grouping) and are much easier to model and refactor in Zanzibar.

Some Zanzibar solutions like SpiceDB and Permify supports ABAC, but OPA language: Rego is more suitable for complex ABAC use cases.
Data Management & Visibility

OPA doesn't have a standard authorization data storage format. Standardizing the authorization data format as Zanzibar does eventually makes Zanzibar-based solutions less prone to errors and much easier to track, monitor, and evaluate the authorization data.
Scalability & Consistency

One of the major goals of Zanzibar based solutions is to provide a horizontally scalable permissions system that can answer thousands or millions of simultaneous permissions questions in 10s of milliseconds, while also providing data consistency to prevent security problems.

In general, here are the major differentiations between Zanzibar-based and Opa-based solutions.

	Zanzibar Based Authorization	Opa Based Authorization
Nature of Access Control	Natural fit for Relationship-based Access Control (ReBAC)	Excels at managing contextual and attribute based policies (e.g., ABAC)
Representation of Relationships	Excellent for representing hierarchies and nested relationships	Can manage relationships with necessary customizations, but not inherently hierarchical
Data Volume Management	Manages high volumes of data consistently	Can struggle with large amounts of data without sharding
Reverse Indices	Supports reverse indices	Does not support reverse indices
Latency	Higher due to non-locality	Lower due to local deployment
Ease of Updates	Less flexible for updates	Highly flexible and easy to update
Ecosystem	Emerging ecosystem	Robust ecosystem with plugins and multiple engines
Learning Curve	Moderate	Can be high due to complex languages