> ## Documentation Index
> Fetch the complete documentation index at: https://openfga.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# What is Google Zanzibar?

> Zanzibar is a 2019 paper from Google describing the authorization system used by Google Drive, YouTube, Calendar, Cloud, and most other Google products. It is the source of the design pattern OpenFGA implements.

[Zanzibar](https://research.google/pubs/zanzibar-googles-consistent-global-authorization-system/) is a 2019 paper from Google describing the authorization system used by Google Drive, YouTube, Calendar, Cloud, and most other Google products. It is the source of the design pattern OpenFGA implements.

## What Zanzibar actually is

Zanzibar is a globally distributed database of **relationship tuples** that answers two questions in milliseconds at Google scale:

1. *"Is user U related to object O via relation R?"* (check)
2. *"What objects of type T is user U related to via relation R?"* (reverse index / list-objects)

Two ideas make it work:

* A **typed schema** (called a *namespace configuration* in the paper) defining types and the relations between them — for example, that `document#viewer` includes `document#editor`.
* A **tuple store** indexed for both forward and reverse queries, with a consistency mechanism (Zookies) that lets clients tie permission checks to the version of the data they read.

## What Zanzibar solved

Before Zanzibar, every Google product had its own authorization layer. Cross-product features ("share a Drive doc to a Calendar event guest") meant authorization logic had to be duplicated and kept in sync. Zanzibar gave Google one model, one store, one decision surface.

<h2 id="how--maps-to-zanzibar">How OpenFGA maps to Zanzibar</h2>

OpenFGA implements the core Zanzibar operations — `Write`, `Read`, `Check`, `Expand`, and `Watch` — and extends them with capabilities that aren't in the paper:

* **Schema** — written in the [OpenFGA DSL](/docs/configuration-language).
* **Tuples** — stored in PostgreSQL, MySQL, or SQLite.
* **Check** and **Expand** — exposed via the [API](/docs/interacting/relationship-queries).
* **ListObjects** and **ListUsers** — reverse queries that aren't in the Zanzibar paper, for answering *"what can this user see?"* and *"who has access to this object?"*.
* **Conditions** (CEL) — also not in the paper; OpenFGA's mechanism for attribute-based decisions, similar in spirit to caveats.

OpenFGA does not replicate Zanzibar's globally distributed Spanner-backed architecture; it is designed to run on your existing databases. For most applications, that's the point — Zanzibar's *model* is what's valuable, not its operational scale.

## Related reading

Learn more about OpenFGA.

<CardGroup>
  <Card title="Zanzibar Academy" href="https://www.zanzibar.academy/">
    A guided walkthrough of the Zanzibar paper.
  </Card>

  <Card title="ReBAC: Relationship-Based Access Control" href="/docs/learn/rebac">
    Relationship-Based Access Control explained.
  </Card>

  <Card title="Fine-Grained Authorization" href="/docs/learn/fine-grained-authorization">
    What FGA is and what it buys you.
  </Card>

  <Card title="Authorization Concepts" href="/docs/authorization-concepts">
    Core authorization terminology.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.