Google Zanzibar Explained: The Authorization Model Behind Modern FGA

Key takeaways

• Zanzibar is Google's internal authorization service, a relationship tuple store with a query language that answers 'can user U do action A on object O?' in tens of milliseconds at billion-tuple scale.
• The data model is intentionally simple: tuples of (object, relation, user) plus a schema defining how relations compose.
• The hard parts are consistency (zookies / new-enough tokens), caching (Leopard inverted index), and replication, not the model itself.
• Open-source Zanzibar-inspired implementations: SpiceDB (AuthZed), OpenFGA (Auth0/Okta), Warrant, Permify, Topaz.
• Most apps don't need Zanzibar-scale; they need Zanzibar-style modeling, relationship-based instead of role-list-based.

What Zanzibar is

The Zanzibar paper is the closest thing the authorization field has to a foundational text. Before it, authorization was either roles in a database table or hand-rolled per-app logic; after it, ReBAC became the default model for products at scale.

The data model

A Zanzibar deployment stores tuples like:

document:roadmap#editor@alice
document:roadmap#viewer@team:engineering#member
folder:product#parent@document:roadmap

Each tuple says one thing: a user (or a userset) has a relation to an object. The schema (Zanzibar calls it a "namespace configuration") declares which relations exist and how they derive:

definition document {
  relation parent: folder
  relation editor: user
  relation viewer: user | team#member

  permission edit = editor + parent->editor
  permission view = viewer + edit
}

parent->editor means "a document inherits editor from its parent folder's editor relation." This is what makes the model powerful: permissions compose through relationships, not enumerated assignments.

Why this beats RBAC

In RBAC, granting "Alice can edit the roadmap document" requires either:

1. A role like roadmap-editor and an assignment row, or
2. A direct ACL entry per object.

Both scale poorly. Roles multiply combinatorially; ACL tables grow with every share.

In Zanzibar, the tuple document:roadmap#editor@alice is the permission, and inheritance through parent->editor is automatic. Sharing a folder shares all documents within. Adding a member to a team grants every team-permissioned object.

For more modeling intuition, see the RBAC vs ABAC vs ReBAC guide and the FGA guide.

The hard parts

The model is simple; the implementation is not.

Consistency. A permission check must reflect recent writes. Zanzibar uses zookies, consistency tokens returned with each write that callers pass to subsequent reads, ensuring "at-least-as-fresh-as this write." A check without a zookie may use stale cached state.

Caching. Naive caching of (user, action, object) tuples doesn't work because relations compose recursively. Zanzibar uses an inverted index ("Leopard") that materializes effective permissions for fast lookup.

Replication. Zanzibar runs in dozens of regions for sub-100ms global latency. The replication protocol is what makes consistency tractable at that scale.

Schema evolution. Permission models change. Zanzibar supports schema versioning so an evolving namespace doesn't break in-flight checks.

Open-source implementations

Several production-grade open-source projects implement Zanzibar's model:

• SpiceDB, AuthZed's open-source implementation; the most mature; offered as managed AuthZed Cloud.
• OpenFGA, Auth0/Okta's open-source implementation; rapidly evolving; on the CNCF sandbox path.
• Warrant, acquired by WorkOS; managed offering.
• Permify, open-source with managed option.
• Topaz, Aserto's open-source authorization with a Zanzibar-style data model plus policy-as-code.

These are not byte-for-byte Zanzibar; they take the data model and check protocol and adapt it to their target scale (typically millions to hundreds of millions of tuples, not billions).

When to reach for it

A simple decision rule:

1. Sharing/collaboration product (Drive-like, Notion-like, Figma-like), Zanzibar-style is the right model from day one.
2. Hierarchical resources (folders, projects, organizations with deep nesting), relationship inheritance pays off quickly.
3. B2B SaaS with per-customer permission models, customers want their own role schemas; ReBAC handles this naturally.
4. CRUD app with a handful of roles, RBAC in a database table is fine; Zanzibar is overkill.

For most teams, the path is: start with RBAC, add ABAC for resource-level rules, migrate to ReBAC when relationship semantics dominate. The migration cost compounds over time, so teams expecting collaboration features often skip RBAC entirely.

What Zanzibar didn't solve

The paper is about checks, answering "can U do A on O." It largely doesn't address:

• Listing. "Show me all documents Alice can edit" requires a different query path than checks. Most Zanzibar-inspired libraries provide list-objects APIs, with caveats about consistency.
• Audit and explanation. "Why does Alice have this permission?" requires tracing the derivation. Production systems add explanation APIs on top of the core check protocol.
• Policy logic beyond relations. Time-of-day rules, attribute conditions, rate limits, these are ABAC concerns. Some libraries (Topaz, Permit.io, Cerbos) layer them; pure Zanzibar does not.

Further reading

The 2019 paper itself is highly readable and the canonical reference. After that, the SpiceDB documentation and OpenFGA documentation are the practical introductions. For the broader authorization landscape, see the FGA guide, RBAC vs ABAC vs ReBAC, and API authorization patterns.