Fine-grained authorization (FGA) has become essential for modern applications and AI projects. While OpenFGA is an incubating CNCF project inspired by Google's Zanzibar paper, it is not the first or only solution for teams needing Relationship-Based Access Control (ReBAC) and other access control solutions. The market for authorization infrastructure includes other direct Zanzibar implementations, general-purpose policy engines, and hybrid solutions. Choosing the right tool depends on your specific requirements for consistency, latency budgets, and operational complexity.
TL;DR
- Alternatives generally fall into two categories: other graph-based engines (Zanzibar-inspired) or policy-based engines (OPA, Cedar) that evaluate rules against data.
- Zanzibar-style systems are superior for "reverse index" queries, such as listing all documents a user can view, which is computationally expensive for policy engines.
- Consistency models vary significantly between tools. Some prioritize eventual consistency, while others offer configurable consistency tokens to prevent stale permission errors.
- Licensing constraints may eliminate certain options immediately, as some open-source projects utilize copyleft licenses like AGPL-3.0.
The two types of alternatives
When engineers search for OpenFGA alternatives, they are usually evaluating two distinct architectural approaches.
The first group consists of Zanzibar-inspired systems. These systems model authorization as a graph of relationships (ReBAC). They excel at solving the "does X have permission to do Y on resource Z" problem at scale and managing permissions for billions of objects.
The second group consists of Policy Decision Points (PDPs). These engines, such as OPA or Cedar, treat authorization as a logic problem solved by evaluating policies against a set of inputs. They are often easier to implement for simple use cases but require additional engineering effort to handle data filtering and search query performance at scale.
Zanzibar-inspired engines
These solutions along with OpenFGA are inspired by the Google Zanzibar paper. They are best suited for applications that require collaborative features, low-latency checks, and the ability to list accessible resources efficiently.
SpiceDB
SpiceDB is an open-source, Zanzibar-inspired database designed specifically for storing and computing permissions. It uses a graph-based data model to handle recursive permission checks and high-volume relationship queries.
A primary differentiator for SpiceDB is its approach to data consistency. It introduces ZedTokens to solve the "New Enemy Problem," a common race condition in distributed systems where a user technically loses access but can still view a resource due to cache staleness. SpiceDB allows developers to configure consistency per request. You can choose between fully consistent reads for critical actions or snapshot reads for highest performance.
AuthZed, the creator and maintainer of SpiceDB, has also introduced Materialize into its commercial product. Materialize is a query accelerator similar to the Zanzibar Leopard indexing system.
SpiceDB supports a variety of storage backends, including PostgreSQL, MySQL, CockroachDB, and Spanner. For teams that need to synchronize permission data to downstream services, it offers a Watch API that streams relationship changes in real time.
Ory Keto
Ory Keto is another open-source permission server written in Go. It is part of the larger Ory identity ecosystem. Like OpenFGA, it translates authorization checks into graph traversals.
Keto focuses on simplicity and integrates tightly with other Ory products like Kratos (identity management). It supports basic tuple management and check APIs. Its subject set expansion APIs help users determine who has access to a specific object. However, configuration options for consistency semantics are less granular compared to SpiceDB. It typically relies on the underlying database's guarantees, which may not be sufficient for globally distributed applications requiring strict causal consistency.
Permify
Permify is an open-source authorization service that also follows the Zanzibar model. It allows developers to model authorization using a custom DSL similar to other ReBAC tools.
Teams evaluating Permify should note its licensing. The core project uses the AGPL-3.0 license. This is a copyleft license that may have legal implications for how the software is deployed and distributed within commercial proprietary stacks. In contrast, OpenFGA and SpiceDB utilize the more permissive Apache-2.0 license. Permify positions itself as a focused solution for easier UI integration, but the architectural fundamentals remain similar to other tuple stores.
Policy engine alternatives
If your application does not require recursive relationship handling or efficient "list objects" APIs, a general-purpose policy engine might be sufficient. These tools decouple policy logic from application code but do not store the relationship data themselves.
Open Policy Agent (OPA)
OPA is the industry standard for general-purpose policy enforcement. It uses a declarative language called Rego to define policies. OPA is widely used for Kubernetes admission control and infrastructure security.
For application authorization, OPA acts as a decision engine. You send it data (JSON), and it returns a decision based on your Rego policies.
The main trade-off is data management. OPA is not a database. To make a decision based on user relationships, you must either bundle that data into the OPA memory (which has size limits) or send it along with every API request. Such architecture makes OPA excellent for attribute-based access control (ABAC) but operationally difficult for relationship-heavy models (ReBAC) where users might share thousands of documents.
AWS Cedar / Amazon Verified Permissions
Cedar is a policy language developed by AWS, designed to be more readable than Rego. It focuses specifically on application permissions rather than general infrastructure policy. Amazon Verified Permissions is the managed service implementation of Cedar.
Cedar is "analyzable," meaning you can use formal verification tools to prove that your policies do exactly what you intend (e.g., ensuring a specific role can never access a specific resource).
Teams adopting Cedar should monitor the language versioning. AWS recently rolled out Cedar v4, and migration between versions can introduce incompatibilities that require policy rewrites or validation updates.
Cerbos
Cerbos is a stateless Policy Decision Point (PDP) that uses YAML to define policies. It is designed to be simpler to adopt than OPA for developers who do not want to learn a complex language like Rego.
Because Cerbos is stateless, it relies entirely on the application to provide the necessary context (user roles, resource attributes) at request time. It includes a specialized Query Plan API to help convert authorization logic into database filters (e.g., SQL WHERE clauses). This feature attempts to solve the listing problem that plagues most policy engines, though it still requires the application to handle the actual data retrieval and filtering logic.
Key evaluation criteria
When benchmarking OpenFGA against its alternatives, focus on these three technical differentiators rather than just feature lists.
Consistency and the "New Enemy"
In distributed authorization, caching is dangerous. If you remove a user from a sensitive group, that change must propagate instantly. If an authorization engine reads from a stale replica, the removed user might retain access for seconds or minutes.
The Google Zanzibar paper highlights this as a critical failure mode. OpenFGA addresses this by offering a "Higher Consistency" preference that routes reads to the primary database, trading latency for correctness. SpiceDB handles this via consistency tokens (ZedTokens) that ensure the authorization check is at least as fresh as the causality token provided. This prevents the "New Enemy Problem" without forcing every check to hit the primary database.
The "List Objects" problem
Checking can_view for one document is easy. Asking "return a list of all documents user X can view" is an order of magnitude harder. Policy engines (OPA, Cedar) struggle here because they don't index the data; they verify inputs. To filter a list, you often have to check permission on every single item in your database.
This limitation becomes critical when building user interfaces. Consider a "Google Drive" style view that needs to show a user every folder they have permission to access. In a policy engine model, the application must fetch all folder metadata, loop through every folder, and ask the policy engine "can User A view Folder X?" for each one. This O(n) operation destroys performance as the dataset grows.
Zanzibar-derived systems index these relationships in reverse. Because the graph knows that "Folder X" is related to "Group Y" and "User A" is in "Group Y," the system can simply query the graph for "all resources where User A has 'viewer' permission" and return the result effectively instantly. This capability is often the deciding factor for applications that require permission-aware search or filtering.
Operational complexity
Running a high-availability authorization service is complex. You are effectively running a specialized database.
- OpenFGA: Requires running the server and a backing datastore (Postgres/MySQL). It supports read replicas but requires careful configuration to manage latency and consistency.
- Policy engines: OPA is often run as a sidecar. This simplifies the network topology (local calls) but pushes the complexity of data synchronization (data.json updates) to the platform team.
- Managed services: Solutions like AuthZed Cloud (for SpiceDB) or AWS Verified Permissions allow teams to offload the storage and compute management, consuming authorization via gRPC or HTTP APIs.
Ecosystem and tooling
The developer experience surrounding an authorization engine is just as important as the engine itself. You will spend significantly more time writing and testing policies than you will operating the server.
OpenFGA provides a robust set of developer tools, including a VS Code extension for syntax highlighting, a CLI for testing models locally, and a Playground for visualizing relationships. Its status as a CNCF project has helped foster a community contributing to these integrations.
SpiceDB has a comprehensive toolset focused on production operations. It includes the zed CLI for managing schema and relationships, a dedicated Kubernetes Operator for Day-2 operations, and official client libraries for major languages (Go, Java, Python, Node.js). AuthZed also provides a playground and visualizer for schema development, ensuring that teams can validate their permissions logic before deploying changes to production.
OPA has perhaps the most mature ecosystem due to its widespread adoption in infrastructure. It boasts extensive tooling for Rego development, including IDE plugins, linters, and a rich library of pre-built policies for common infrastructure use cases. However, its tooling for application-level authorization data management is less specialized than the dedicated ReBAC options.
Conclusion
Choosing an alternative to OpenFGA is rarely about finding a tool that does the exact same thing but slightly differently. It is usually a decision about architectural fit. If your application relies on simple roles and attributes without complex hierarchies, a policy engine like OPA or Cedar offers a valid path. However, for applications requiring fine-grained sharing, nested groups, or list-filtering performance, a Zanzibar-inspired system is the correct model. Among the Zanzibar implementations, differentiation comes down to operational maturity and correctness guarantees. AuthZed takes a strong stance on correctness, using SpiceDB to offer tunable consistency that prevents authorization bugs caused by stale data. By enforcing strict consistency where it matters and allowing scalable reads where it doesn't, it provides a safe, production-ready path for fine-grained authorization services.
FAQs
What is the difference between OPA and OpenFGA?
OPA is a general-purpose policy engine that evaluates rules against input data, while OpenFGA is a dedicated relationship-based access control (ReBAC) system that stores authorization data as a graph. OPA is stateless and best for attribute-based control, whereas OpenFGA is stateful and excels at handling complex user relationships and hierarchies.
Is OpenFGA production ready?
OpenFGA is a CNCF Incubating project as of October 2025, signaling stable governance and adoption. However, users must manage the operational complexity of scaling the backing database and handling read replicas to ensure high availability and consistency.
Can I use OPA for relationship-based access control (ReBAC)?
You can implement ReBAC in OPA, but it is often inefficient at scale because OPA does not store the relationship graph natively. You must either load all relationship data into OPA's memory, which is memory-constrained, or fetch data during every request, which adds significant latency.
What databases does SpiceDB support?
SpiceDB supports several storage engines including PostgreSQL, MySQL, CockroachDB, and Google Cloud Spanner. This allows teams to run SpiceDB on their existing database infrastructure or utilize distributed SQL databases for global scale.
Is Permify open source?
Permify is open source, but it is licensed under the AGPL-3.0 license. This is a copyleft license that requires any network-accessible service based on the code to also be open-sourced under the same terms, which can be restrictive for some commercial deployments compared to Apache-2.0.