SpiceDB vs Auth0 FGA: Relationship-Based Authorization Compared

Abstract#

SpiceDB and Auth0 FGA are the two leading Zanzibar-inspired authorization systems, but they make fundamentally different trade-offs. SpiceDB offers a gRPC-first, self-hosted (or managed via Authzed) engine with strong consistency guarantees through ZedTokens. Auth0 FGA provides a REST-first, fully managed service built on OpenFGA with a different consistency model. This post compares their schema languages, architecture, consistency models, and integration patterns side-by-side -- with working TypeScript examples for both -- to help you choose the right one for your system.

Note: This is Part 3 of the External Authorization Systems series. Part 1 covers the full platform landscape, and Part 2 focuses on AWS Cognito + Verified Permissions for SaaS.

Google Zanzibar Heritage#

Both SpiceDB and Auth0 FGA trace their design back to the same source: Google's Zanzibar paper, published at USENIX ATC 2019. Zanzibar is Google's internal authorization system that powers permissions for Drive, Calendar, Cloud, Maps, Photos, and YouTube. It handles trillions of access control lists and millions of authorization requests per second with 95th-percentile latency under 10 milliseconds.

The Zanzibar paper introduced several concepts that both systems implement:

• Relationship tuples: The atomic unit of authorization data -- (user, relation, object). "User X is editor of Document Y" becomes a tuple.
• Namespace configuration: A schema that defines what types of objects exist and what relations they can have.
• Relation rewriting: Computing permissions by traversing and combining relationships. "Can view" might mean "is a viewer OR is an editor OR is an owner."
• Consistency tokens: Mechanisms to ensure that permission checks reflect recent writes (Zanzibar calls these "zookies").

Where SpiceDB and Auth0 FGA diverge is in how faithfully they implement these concepts and what trade-offs they make around consistency, deployment, and API design.

SpiceDB implements the full Zanzibar consistency model, including at_least_as_fresh and fully_consistent semantics. Auth0 FGA (via OpenFGA) takes a more relaxed approach, offering HIGHER_CONSISTENCY as an opt-in flag rather than token-based consistency by default.

Schema Comparison#

The schema is where you model your authorization logic. Both systems use a declarative language for defining types, relations, and permissions, but the syntax and capabilities differ.

SpiceDB Schema Language#

SpiceDB uses its own schema language with definition blocks, relation declarations, and permission computations. Relations define what types of subjects can be assigned. Permissions define computed access by combining relations with set operations.

// SpiceDB schema: document management with organizationsdefinition user {}
definition organization {    relation admin: user    relation member: user
    permission manage = admin}
definition folder {    relation org: organization    relation viewer: user | organization#member    relation editor: user | organization#admin
    permission view = viewer + editor    permission edit = editor}
definition document {    relation parent_folder: folder    relation owner: user    relation editor: user    relation viewer: user
    permission view = viewer + editor + owner + parent_folder->view    permission edit = editor + owner + parent_folder->edit    permission delete = owner}

Key features of the SpiceDB schema:

• Arrow operator (->): Follows relationships across objects. parent_folder->view means "anyone who can view the parent folder can also view this document."
• Union (+): Combines multiple relations. viewer + editor + owner means any of those relations grants the permission.
• Intersection (&) and exclusion (-): Support for AND and NOT logic in permission computation.
• Subject relations (organization#member): References subjects through their relations, not just their identity.

OpenFGA DSL (Auth0 FGA)#

Auth0 FGA uses the OpenFGA DSL, which has a different syntax but models similar concepts. Types replace definitions, and the define keyword declares both relations and permissions.

model  schema 1.1
type user
type organization  relations    define admin: [user]    define member: [user]    define manage: admin
type folder  relations    define org: [organization]    define viewer: [user, organization#member]    define editor: [user, organization#admin]    define view: viewer or editor    define edit: editor
type document  relations    define parent_folder: [folder]    define owner: [user]    define editor: [user]    define viewer: [user]    define view: viewer or editor or owner or view from parent_folder    define edit: editor or owner or edit from parent_folder    define delete: owner

Key features of the OpenFGA DSL:

• from keyword: Equivalent to SpiceDB's arrow operator. view from parent_folder follows the parent_folder relation and checks view permission.
• or / and / but not: Set operations expressed with keywords rather than symbols.
• Type restrictions in brackets: [user, organization#member] specifies which subject types are allowed in a relation.
• No separate permission keyword: Relations and permissions use the same define syntax. The distinction is implicit -- relations that reference [type] are assignable; those that reference other relations are computed.

Schema Comparison Table#

Both schemas model the same authorization logic. The choice between them is largely about syntax preference and the broader ecosystem each connects to.

Architecture Differences#

The architectural differences between SpiceDB and Auth0 FGA reflect their different design philosophies: self-hosted flexibility versus managed simplicity.

SpiceDB#

• Protocol: gRPC-first with an optional HTTP/REST gateway. gRPC is the primary integration path and offers better performance characteristics (HTTP/2, binary protocol, streaming).
• Deployment: Self-hosted on Kubernetes, Docker, or bare metal. Authzed offers a managed service for teams that prefer not to run infrastructure.
• Storage backends: PostgreSQL, CockroachDB, MySQL, or Memdb (in-memory for testing). CockroachDB enables horizontally scaled deployments with strong consistency.
• Scaling: Horizontal scaling via multiple SpiceDB instances backed by a shared datastore. Cache layers reduce datastore load for read-heavy workloads.

Auth0 FGA#

• Protocol: REST-first (HTTPS). SDKs abstract the REST calls, but the underlying API is HTTP/JSON.
• Deployment: Fully managed SaaS. No self-hosting option for Auth0 FGA itself, though you can self-host OpenFGA (the open-source engine) if needed.
• Storage: Managed by Okta. Multi-region deployment in US, EU, and Australia. Private cloud deployment available on AWS.
• Scaling: Managed scaling handled by the platform. Okta publishes upper-bound figures (for example, on the order of 100 billion relationships and 1 million requests per second). Treat these as vendor documentation and marketing, not a guarantee for every tenant, region, or pricing tier. Confirm quotas, plans, and SLA terms in your contract.

Architecture Comparison Table#

Code Examples#

The following examples implement the same scenario in both systems: a document management application where users can be assigned as owners, editors, or viewers, and permissions flow through folder hierarchies.

SpiceDB with TypeScript#

SpiceDB uses the @authzed/authzed-node client library, which communicates over gRPC.

import { v1 } from "@authzed/authzed-node";
// Initialize the SpiceDB client (gRPC)const client = v1.NewClient(  "spicedb-preshared-key",  "localhost:50051",  v1.ClientSecurity.INSECURE_LOCALHOST_ALLOWED);
// --- Write relationships ---const writeResponse = await client.writeRelationships(  v1.WriteRelationshipsRequest.create({    updates: [      {        operation: v1.RelationshipUpdate_Operation.TOUCH,        relationship: {          resource: { objectType: "document", objectId: "doc-roadmap" },          relation: "editor",          subject: {            object: { objectType: "user", objectId: "alice" },          },        },      },      {        operation: v1.RelationshipUpdate_Operation.TOUCH,        relationship: {          resource: { objectType: "document", objectId: "doc-roadmap" },          relation: "viewer",          subject: {            object: { objectType: "user", objectId: "bob" },          },        },      },    ],  }));
// writeResponse.writtenAt contains the ZedToken for consistencyconst zedToken = writeResponse.writtenAt;
// --- Check permission ---const checkResult = await client.checkPermission(  v1.CheckPermissionRequest.create({    consistency: {      requirement: {        oneofKind: "atLeastAsFresh",        atLeastAsFresh: zedToken, // Ensure this read reflects our write      },    },    resource: { objectType: "document", objectId: "doc-roadmap" },    permission: "edit",    subject: {      object: { objectType: "user", objectId: "alice" },    },  }));
const canEdit =  checkResult.permissionship ===  v1.CheckPermissionResponse_Permissionship.HAS_PERMISSION;// canEdit === true (alice is an editor)
// --- Lookup resources ---// Find all documents that bob can viewconst lookupStream = client.lookupResources(  v1.LookupResourcesRequest.create({    consistency: {      requirement: {        oneofKind: "atLeastAsFresh",        atLeastAsFresh: zedToken,      },    },    resourceObjectType: "document",    permission: "view",    subject: {      object: { objectType: "user", objectId: "bob" },    },  }));
// lookupResources returns a stream of matching resource IDsconst accessibleDocs: string[] = [];for await (const response of lookupStream) {  accessibleDocs.push(response.resourceObjectId);}// accessibleDocs includes "doc-roadmap" (bob is a viewer)

Auth0 FGA with TypeScript#

Auth0 FGA uses the @openfga/sdk client library, which communicates over REST.

import { OpenFgaClient, ConsistencyPreference } from "@openfga/sdk";
// Initialize the OpenFGA client (REST)const fgaClient = new OpenFgaClient({  apiUrl: process.env.FGA_API_URL!,  // e.g., https://api.us1.fga.dev  storeId: process.env.FGA_STORE_ID!,  authorizationModelId: process.env.FGA_MODEL_ID!,  credentials: {    method: "client_credentials",    config: {      clientId: process.env.FGA_CLIENT_ID!,      clientSecret: process.env.FGA_CLIENT_SECRET!,      apiTokenIssuer: "fga.us.auth0.com",      apiAudience: "https://api.us1.fga.dev/",    },  },});
// --- Write tuples ---await fgaClient.write({  writes: [    {      user: "user:alice",      relation: "editor",      object: "document:doc-roadmap",    },    {      user: "user:bob",      relation: "viewer",      object: "document:doc-roadmap",    },  ],});
// --- Check permission ---const { allowed } = await fgaClient.check({  user: "user:alice",  relation: "edit",  object: "document:doc-roadmap",}, {  consistency: ConsistencyPreference.HigherConsistency,});// allowed === true (alice is an editor, edit = editor or owner)
// --- List objects ---// Find all documents that bob can viewconst { objects } = await fgaClient.listObjects({  user: "user:bob",  relation: "view",  type: "document",}, {  consistency: ConsistencyPreference.HigherConsistency,});// objects includes "document:doc-roadmap" (bob is a viewer)

Side-by-Side API Comparison#

The Dual-Write Problem#

Both SpiceDB and Auth0 FGA are external stores. Your application data lives in your database. Authorization relationships live in the authorization system. Keeping these two in sync is the dual-write problem, and it is the most underestimated operational challenge of relationship-based authorization.

The Problem#

Consider creating a document with an owner:

1. Application writes the document record to PostgreSQL
2. Application writes user:alice is owner of document:doc-123 to SpiceDB (or Auth0 FGA)
3. If step 2 fails, the document exists but has no authorization data

The reverse is equally dangerous: if step 1 fails but step 2 succeeds, the authorization system references a document that does not exist.

There is no distributed transaction between your database and the authorization system. You need a pattern to handle this.

Transactional Outbox Pattern#

The most reliable solution is the transactional outbox pattern. Write both the application data and the authorization event to the same database in a single transaction. A separate worker process then reads the outbox and syncs to the authorization store.

// Transactional outbox: single DB transaction for both writesasync function createDocument(  db: Database,  doc: { id: string; title: string; ownerId: string }): Promise<void> {  await db.transaction(async (tx) => {    // Application write    await tx.insert(documents).values({      id: doc.id,      title: doc.title,      ownerId: doc.ownerId,      createdAt: new Date(),    });
    // Outbox write (same transaction -- atomic)    await tx.insert(authzOutbox).values({      eventType: "relationship_created",      payload: JSON.stringify({        resource: { type: "document", id: doc.id },        relation: "owner",        subject: { type: "user", id: doc.ownerId },      }),      status: "pending",      createdAt: new Date(),    });  });}
// Async worker: reads outbox and syncs to SpiceDB or Auth0 FGAasync function processOutbox(  db: Database,  authzClient: AuthZClient): Promise<void> {  const pending = await db    .select()    .from(authzOutbox)    .where(eq(authzOutbox.status, "pending"))    .orderBy(authzOutbox.createdAt)    .limit(100);
  for (const event of pending) {    try {      const payload = JSON.parse(event.payload);
      // Write to SpiceDB or Auth0 FGA      await authzClient.writeRelationship({        resource: payload.resource,        relation: payload.relation,        subject: payload.subject,      });
      // Mark as processed      await db        .update(authzOutbox)        .set({ status: "processed", processedAt: new Date() })        .where(eq(authzOutbox.id, event.id));    } catch (error) {      // Mark as failed with retry logic      await db        .update(authzOutbox)        .set({          status: "failed",          retryCount: event.retryCount + 1,          lastError: error.message,        })        .where(eq(authzOutbox.id, event.id));    }  }}

Alternative Approaches#

Change Data Capture (CDC): Use Debezium or a similar tool to capture database changes and propagate them to the authorization store. More complex to set up but decouples the application from the sync mechanism entirely.

Reconciliation jobs: Accept brief inconsistency and run periodic jobs to compare application state with authorization state, fixing any drift. This is the simplest approach but introduces a window where permissions may be wrong.

Warning: Budget meaningful engineering time for synchronization. The dual-write problem is the most commonly underestimated cost of adopting external authorization systems. AuthZed has published detailed guidance on this topic based on their experience with Google Zanzibar and SpiceDB at scale.

Consistency Models#

Consistency is where SpiceDB and Auth0 FGA differ most significantly. It directly affects whether a recently revoked permission is still honored -- the "New Enemy Problem" from the Zanzibar paper.

ZedTokens (SpiceDB)#

SpiceDB implements the full Zanzibar consistency model through ZedTokens (the equivalent of Zanzibar's "zookies"). Every write operation returns a ZedToken. Passing this token on subsequent reads guarantees that the read reflects at least that write.

SpiceDB offers three consistency modes per request:

The per-request consistency model is a significant advantage. You can use minimize_latency for rendering UI elements (where brief staleness is fine) and fully_consistent for write operations or sensitive access checks.

// SpiceDB: per-request consistency control// Fast check for UI rendering (may use cache)const uiCheck = await client.checkPermission(  v1.CheckPermissionRequest.create({    consistency: {      requirement: { oneofKind: "minimizeLatency", minimizeLatency: true },    },    resource: { objectType: "document", objectId: "doc-123" },    permission: "view",    subject: { object: { objectType: "user", objectId: "alice" } },  }));
// Strict check before allowing a destructive actionconst deleteCheck = await client.checkPermission(  v1.CheckPermissionRequest.create({    consistency: {      requirement: { oneofKind: "fullyConsistent", fullyConsistent: true },    },    resource: { objectType: "document", objectId: "doc-123" },    permission: "delete",    subject: { object: { objectType: "user", objectId: "alice" } },  }));

Consistency in Auth0 FGA (OpenFGA)#

OpenFGA (starting with v1.5.7) offers a HIGHER_CONSISTENCY flag on query APIs. When set, OpenFGA bypasses its read cache and routes queries to the primary database instead of read replicas.

// Auth0 FGA: consistency flagconst { allowed } = await fgaClient.check({  user: "user:alice",  relation: "delete",  object: "document:doc-123",}, {  consistency: ConsistencyPreference.HigherConsistency,});

This is a binary choice rather than SpiceDB's three-tier model. There is no equivalent to SpiceDB's at_least_as_fresh with a specific token -- you either get default consistency (potentially stale due to caching and replicas) or higher consistency (direct primary read).

Tip: OpenFGA's roadmap includes full consistency token support (similar to ZedTokens), where write operations return a token that can be passed to subsequent reads. As of OpenFGA v1.8, this feature is still in progress.

Consistency Comparison#

For applications where permission revocation must be immediately enforced (security-sensitive systems, financial applications), SpiceDB's consistency model provides stronger guarantees today. For applications where brief staleness is acceptable (content platforms, collaboration tools), Auth0 FGA's simpler model may be sufficient.

Scalability#

Both systems have been validated at significant scale, though their scaling stories are different.

SpiceDB at Scale#

SpiceDB's most notable deployment is at OpenAI, where it powers authorization for ChatGPT Enterprise connectors. This handles tens of billions of fine-grained permissions. AuthZed (the company behind SpiceDB) positions the system for AI agent authorization scenarios where permission checks happen at high frequency with complex relationship graphs.

Scaling SpiceDB involves:

• Horizontal scaling: Add more SpiceDB instances behind a load balancer. All instances share the same datastore.
• Storage backend choice: CockroachDB for horizontally scalable, strongly consistent storage. PostgreSQL for simpler deployments with vertical scaling. MySQL as an alternative relational backend.
• Caching: SpiceDB caches frequently accessed relationships. The minimize_latency consistency mode maximizes cache utilization.
• Watch API: Enables cache invalidation patterns for downstream consumers.

Auth0 FGA at Scale#

Auth0 FGA (Okta FGA) publishes high-scale figures (relationship count, requests per second) and an availability target in product materials. Those numbers describe the platform design envelope, not an automatic commitment for every customer. SLA, regions, and quotas depend on your Okta contract and SKU -- validate what you rely on in writing. Scaling is handled entirely by the platform -- you do not manage infrastructure.

Key scaling characteristics:

• Multi-region: Automatic deployment across US, EU, and Australia regions.
• Private cloud: Available on AWS for organizations with data residency requirements.
• Managed scaling: Okta handles capacity planning, failover, and performance optimization.
• OpenFGA self-hosted: If you outgrow the managed service or need custom deployment, OpenFGA can be self-hosted with PostgreSQL or MySQL.

Scale Comparison#

Self-Hosted vs. Managed Trade-offs#

The decision between self-hosting SpiceDB and using Auth0 FGA as a managed service goes beyond technical preference. It involves operations burden, compliance, cost, and organizational capability.

When Self-Hosted SpiceDB Makes Sense#

• Data sovereignty: Authorization data must stay within specific geographic or network boundaries. Self-hosting gives full control over data residency.
• Custom storage requirements: You need a specific database backend (CockroachDB for multi-region consistency, for example) or custom backup/recovery procedures.
• Cost optimization at scale: At very high authorization volumes, self-hosting can be more cost-effective than per-request pricing. Infrastructure cost for a production SpiceDB cluster typically ranges from $500-2,000/month depending on scale.
• Deep integration needs: Direct access to the gRPC API, Watch API for streaming changes, or custom caching layers.
• Existing Kubernetes expertise: If your team already operates Kubernetes clusters, adding SpiceDB is incremental rather than a new operational domain.

When Auth0 FGA Makes Sense#

• Minimal operational overhead: No infrastructure to manage, no database to tune, no scaling decisions to make.
• Auth0/Okta ecosystem: If you already use Auth0 for authentication, FGA integrates naturally with your existing identity infrastructure.
• Quick adoption: REST APIs with official SDKs in multiple languages. Shorter time-to-production compared to self-hosted SpiceDB.
• SLA requirements: A vendor-managed SLA (where it applies to your SKU) can be easier to rely on operationally than matching the same target on self-hosted infrastructure -- still verify coverage in your agreement.
• Team size constraints: Small teams that cannot dedicate engineering capacity to authorization infrastructure benefit from a managed service.

Trade-off Matrix#

Decision Matrix#

The following flowchart helps navigate the SpiceDB vs. Auth0 FGA decision based on your specific requirements.

Quick Decision Guide#

What Not to Do#

• Do not choose SpiceDB just because it is open-source if your team lacks Kubernetes and database operations expertise. The operational overhead can outweigh the benefits.
• Do not choose Auth0 FGA assuming consistency tokens work like ZedTokens. The consistency models are meaningfully different. If you need at_least_as_fresh semantics, test Auth0 FGA's current consistency model against your requirements.
• Do not skip the dual-write problem analysis. Both systems require a synchronization strategy. Choosing either platform without a plan for keeping authorization data in sync with application data will lead to production issues.
• Do not ignore OpenFGA as a middle path. Self-hosting OpenFGA gives you the Auth0 FGA schema language with self-hosted control. If you later need managed infrastructure, migrating to Auth0 FGA is straightforward since the underlying model is the same.

Conclusion#

SpiceDB and Auth0 FGA are both mature, production-validated Zanzibar implementations. They solve the same fundamental problem -- relationship-based authorization at scale -- but with different trade-offs.

SpiceDB provides stronger consistency guarantees through ZedTokens, gRPC-first performance, and full infrastructure control. It requires more operational investment but rewards teams that need fine-grained consistency control and data sovereignty.

Auth0 FGA provides a managed, REST-first experience with strong scalability guarantees and native Auth0 integration. It trades consistency granularity for operational simplicity and faster time to production.

The dual-write problem applies equally to both. Regardless of which system you choose, plan for how authorization data stays synchronized with application data. The transactional outbox pattern is the most reliable approach for most architectures.

Run a proof of concept with your most complex authorization scenario. Model your schema in both systems (use play.authzed.com and play.fga.dev), integrate with your application code, and evaluate the consistency model against your security requirements. The right choice becomes clear once you see both systems handling your specific use case.

References#

• Zanzibar: Google's Consistent, Global Authorization System (USENIX ATC 2019) - The original Google Zanzibar paper that inspired both SpiceDB and OpenFGA
• AuthZed SpiceDB GitHub Repository - Open-source Google Zanzibar-inspired authorization system
• SpiceDB Consistency Documentation - Official documentation on ZedTokens and consistency modes
• SpiceDB Schema Language Reference - Schema definition syntax and capabilities
• authzed-node GitHub Repository - Official SpiceDB client library for Node.js/TypeScript
• OpenFGA Documentation - Core concepts of the OpenFGA authorization model
• OpenFGA Query Consistency Modes - Documentation on HIGHER_CONSISTENCY and query consistency options
• Auth0 Fine-Grained Authorization (FGA) Documentation - Official Auth0 FGA documentation and integration guides
• Okta Fine Grained Authorization Product Page - Auth0/Okta FGA product overview and scalability documentation
• AuthZed - The Dual-Write Problem in SpiceDB - Deep dive into synchronization challenges with external relationship stores
• OpenFGA Consistency Tokens Roadmap Issue - OpenFGA roadmap for Zanzibar-style consistency tokens
• Permit.io - Policy Engine Showdown: OPA vs OpenFGA vs Cedar - Comprehensive policy engine comparison with syntax examples