SpiceDB

SpiceDB is an open source database purpose-built for one job: answering “can subject X perform action Y on resource Z?” quickly and correctly, no matter how large the dataset or how complex the permission model. It is the most mature open implementation of Google’s internal Zanzibar system, the paper that describes how Google powers access control for Calendar, Drive, Photos, and Cloud IAM. Rather than bolting authorization onto an existing relational or key-value store, SpiceDB is a dedicated service that developers define a schema against, write relationship tuples into, and query through gRPC or HTTP client libraries.

The core model is relationship-based access control (ReBAC): developers write a schema describing object types (documents, folders, organizations) and the relations between them (viewer, editor, parent), then SpiceDB computes permissions by walking that relationship graph — for example, a user can view a document if they are a direct viewer, or if they can view the folder that contains it. SpiceDB extends this with caveated relationships, which attach CEL (Common Expression Language) conditions to a relationship so a grant can depend on runtime context like IP range, time of day, or resource attributes — effectively blending ReBAC with attribute-based access control (ABAC) in a single system.

Operationally, SpiceDB is built to run as a centralized authorization service shared across microservices, with pluggable storage backends (PostgreSQL, MySQL, CockroachDB, Google Cloud Spanner, or in-memory for development) sitting behind a common datastore interface, and a distributed dispatch layer that uses consistent hashing to route permission checks across a cluster while keeping cache hit rates high. Per-request consistency tuning (via “zedtokens”) lets callers choose between fully consistent reads and faster, slightly stale ones, which is how AuthZed advertises 5ms p95 latency at millions of queries per second.

SpiceDB is maintained by AuthZed, which also sells a hosted cloud version, but the open source project itself carries no license-gated features. It has been adopted by organizations including IBM, Red Hat, and GitPod for exactly the problem it was built to solve: keeping authorization logic out of application code and correct as systems scale.

What You Get

• A dedicated authorization service with a real schema language, validated in real time or in CI, rather than ad hoc permission checks spread across services
• Pluggable storage backends — PostgreSQL, MySQL, CockroachDB, Google Cloud Spanner, or in-memory — behind a single datastore interface, so the same schema and API work from a laptop to a multi-region cluster
• Caveated relationships that attach CEL expressions to permission grants, combining relationship-based (ReBAC) and attribute-based (ABAC) access control in one model
• A distributed dispatch layer using consistent hashing to fan permission checks out across a cluster while preserving cache locality, plus per-request consistency tokens (zedtokens) to trade off freshness for latency
• The zed CLI and a hosted Playground for writing, testing, and validating schemas and relationships before they hit production
• Reverse-index queries — “what can this subject access?” and “who can access this resource?” — in addition to simple boolean permission checks

Common Use Cases

• Centralizing authorization for a microservice architecture so every service checks permissions against one source of truth instead of reimplementing access logic
• Modeling deeply nested resource hierarchies (folders within folders, teams within organizations) where permissions inherit down the tree
• Adding conditional, context-aware access rules — like restricting access by IP range or time window — on top of an existing relationship-based permission model via caveats
• Replacing hand-rolled RBAC/ACL tables in a relational database with a purpose-built system that scales permission checks independently of the main application database
• Powering “share with…” and “who has access” features in collaboration products by using SpiceDB’s reverse-index lookups instead of scanning application tables

Under The Hood

Architecture SpiceDB is organized as a set of clearly separated layers: cmd/spicedb is a thin binary that wires up pkg/cmd (server construction, config, CLI commands) into gRPC services under internal/services/v1; those services delegate permission logic to a dispatcher (internal/dispatch), which either resolves checks locally or fans them out across a cluster via a consistent-hashring dispatcher (internal/dispatch/cluster) before handing off to the core Zanzibar graph algorithms in internal/graph (check, expand, lookup-resources, lookup-subjects); those algorithms read through a pluggable internal/datastore interface implemented separately for Postgres, MySQL, CockroachDB, Spanner, and an in-memory engine. The schema compiler (pkg/schemadsl) and the CEL-based caveat evaluator (pkg/caveats) are independent concerns that plug into the graph layer rather than being entangled with it. Dependency injection favors functional options (seen throughout internal/dispatch/cluster) over globals. The two load-bearing seams are the Datastore interface and the Dispatcher interface — either changing shape would ripple through every storage backend or every graph algorithm respectively, which is exactly why both are isolated behind their own packages.

Tech Stack The project is Go (module targets a current Go toolchain), exposing its API as gRPC with an HTTP gateway generated from protobuf via buf.build tooling. Storage is genuinely pluggable: PostgreSQL and MySQL drivers, native CockroachDB support, Google Cloud Spanner, and an in-memory go-memdb backend for tests and local development all satisfy the same datastore contract. Caveated (attribute-based) relationships are evaluated with a forked copy of Google’s cel-go expression engine. Observability leans on OpenTelemetry tracing, Prometheus metrics, and zerolog logging; cluster-awareness comes from a Kubernetes-aware gRPC resolver and a consistent-hashring load balancer for horizontal scale-out. Builds and releases run through Mage and GoReleaser, with container images built on minimal Chainguard base images.

Code Quality The repository pairs a large body of implementation code with an extensive parallel test suite, and enforces a strict golangci-lint configuration covering security (gosec), correctness (errcheck, errorlint, staticcheck, ineffassign), resource-leak detection (bodyclose, rowserrcheck), and style consistency across dozens of enabled linters. Errors flow through a dedicated spiceerrors package that wraps and types failures rather than passing bare strings, and a companion “bug” assertion package flags invariant violations distinctly from ordinary errors. CI is split into dedicated workflows for linting, build/test, security scanning, commit-message conventions, and performance benchmarking, and the codebase carries package-level documentation comments (doc.go files) across the large majority of its internal and public packages — an unusually thorough documentation discipline for a project this size.

What Makes It Unique What distinguishes SpiceDB from a plain reimplementation of the Zanzibar paper is the combination of caveated relationships — CEL expressions attached directly to relationship tuples, so a grant can depend on runtime context rather than being purely structural — with a genuinely pluggable multi-backend datastore and a consistent-hash-based cluster dispatcher that keeps repeated permission checks cache-local as the system scales horizontally. Few open source authorization systems offer all three simultaneously: a real, independently compiled schema language, ABAC-style conditional grants layered onto a ReBAC graph, and per-request consistency tuning for the freshness/latency tradeoff. That combination is why SpiceDB is used as a shared, centralized authorization layer rather than a library embedded in a single application.

Self-Hosting

Licensing Model Apache-2.0 licensed — the entire SpiceDB codebase, including clustering, multi-backend datastore support, and caveated relationships, is available with no license keys or feature gating in self-hosted deployments.

Self-Hosting Restrictions None found. There are no ee/, enterprise/, or pro/ directories in the repository, and no license-check code paths in the source.

Cloud vs Self-Hosted AuthZed, the company behind SpiceDB, sells a managed cloud offering (AuthZed Dedicated/Cloud) for teams that don’t want to operate the datastore and dispatch cluster themselves, but this is an operational convenience rather than a feature difference — the underlying engine is the same open source project.

License Key Required No.