SpiceDB: a Zanzibar-inspired authorization database for permission checks at scale

The problem SpiceDB solves, and who ends up owning it

Most applications start with a role column and a handful of checks. Then the product asks for sharing, then for nested teams, then for per-document exceptions, and the checks spread across services that disagree with each other. SpiceDB targets exactly that drift. The README frames the core question as "can subject X perform action Y on resource Z?" and positions the project as a centralized service shared across product suites and microservice architectures.

The intended audience is platform and product teams, not individual application developers. SpiceDB is deliberately agnostic to authentication and identity providers: it does not log users in, it does not store credentials, it decides what an already-identified subject may do. That separation is the main design decision to accept before adopting it. If your identity provider already ships a policy engine you are happy with, adding SpiceDB means adding a second system that must stay consistent with the first.

The README also cites OWASP's 2021 ranking of broken access control as the top web security risk. That is context, not a benchmark, and it is worth reading as motivation rather than evidence that adopting SpiceDB removes the risk. The risk moves into your schema: a relationship written incorrectly is still an access-control bug, just one that lives in a different repository.

Schema, relationships and permission checks: how the data actually flows

The README describes the model by analogy to a relational database: developers define a schema, write data as relationships, then use clients to issue permission checks. A schema declares object types and the relations and permissions between them. Relationships are the tuples that populate those types at runtime. Permission checks are the queries.

Two other query shapes matter as much as the check. The README lists "What can subject do?" and "Who can access resource?" and links these to reverse indexes in the documentation. This is the part teams underestimate: a reverse index is what lets you render a list of everything a user can see without walking every object in your system. If your product has no such screen, you are paying for a capability you may not use.

Consistency is configured per request. The README lists this under why SpiceDB, pointing at a concepts page on consistency. The practical consequence is that a check can be tuned toward freshness or toward latency on a per-call basis rather than globally, which is unusual for a datastore and is the main reason the project describes itself as Zanzibar-inspired rather than as a plain graph store. Caveated relationships are the other extension: the README describes them as combining ABAC and ReBAC, and links to a Netflix engineering post about ABAC on SpiceDB. That link is third-party material, not part of this repository.

On deployment, the repository ships compose files for several datastores: docker-compose.postgres.yaml, docker-compose.mysql.yaml, docker-compose.spanner.yaml, docker-compose.pgbouncer.yaml and docker-compose.memdb.yaml. A single docker-compose.yaml also exists and its header comment says "FOR DEVELOPMENT ONLY". The presence of a pgbouncer variant is a signal worth noting: connection pooling in front of the datastore is treated as a real deployment shape, not an afterthought.

Running SpiceDB with Docker and writing a first schema

The repository's development compose file starts CockroachDB, applies migrations, then brings up two SpiceDB nodes behind Envoy. The comment in that file explains the choice: Envoy balances individual RPCs over HTTP/2, whereas nginx would pin a client's RPCs to one backend. The migration step is a separate container that runs the datastore migrate command with the CockroachDB engine and connection URI set as environment variables:

  migrate:
    environment:
      - "SPICEDB_DATASTORE_ENGINE=cockroachdb"
      - "SPICEDB_DATASTORE_CONN_URI=postgresql://root@crdb:26257/defaultdb?sslmode=disable"
    command: "datastore migrate head"

Bringing that stack up means running docker compose against the file in the repository root. What you should see is the migration container exiting successfully before the SpiceDB services report healthy. If the migration container fails, nothing downstream starts, which is the intended ordering.

For a container without the surrounding stack, the Dockerfile builds the binary and exposes port 50051, with the entrypoint set to spicedb:

COPY --from=spicedb-builder /go/src/app/spicedb /usr/local/bin/spicedb
ENV PATH="$PATH:/usr/local/bin"
EXPOSE 50051
ENTRYPOINT ["spicedb"]

The image is built from a Chainguard static base and also copies in grpc_health_probe, so health checking over gRPC is available without installing anything extra. The port to remember is 50051; the development compose file maps the same port for the Envoy front end, and 8443 for HTTP.

Schema and relationship writes go through the API rather than SQL. The README points at the authzed.com documentation for modeling, including a page on validation, testing and debugging. That page is where the real workflow lives: write a schema, validate it, and wire that validation into CI/CD so a broken permission definition fails a build instead of a request. The repository itself does not document the schema syntax in the README, so treat the docs site as the reference.

Where SpiceDB is the wrong tool

The most common mismatch is expecting a user interface. The README's own FAQ link addresses reverse indexes, and the related searches around a SpiceDB UI reflect the same expectation, but nothing in the repository describes an admin console. SpiceDB is a database with an API. If your operators need to click through permissions to debug them, you are building that surface yourself on top of the check and reverse-index APIs.

A second mismatch is latency budget. SpiceDB is a network service in front of a datastore. A permission check is an RPC, not a function call. The README cites a figure of 5ms p95 at very large scale, but that is a vendor blog claim about their own deployment, not a property of your installation. Anyone whose authorization decisions sit on a hot path with a sub-millisecond budget should measure before adopting, and should expect to cache or batch.

Third, SpiceDB is not an authentication system and does not want to be. If you were hoping to consolidate login, sessions and permissions into one component, this is the wrong project by design.

Finally, the operational surface is real. You must run the service, run a supported datastore, and run migrations. The repository carries compose files for Postgres, MySQL, Spanner, pgbouncer and an in-memory engine, which is convenient, but each of those is a different set of failure modes. The in-memory engine in particular is a development convenience, not a persistence strategy.

SpiceDB against OpenFGA and against a relational database

OpenFGA is the closest comparison and the one people search for. Both implement the Zanzibar model: object types, relations, and check queries over an API. The difference in approach is in the surrounding commitments rather than in the tuple model. SpiceDB is written in Go, ships as a single binary and container, and its repository includes compose files for CockroachDB, Postgres, MySQL, Spanner and pgbouncer, plus an Envoy configuration for RPC-level balancing across nodes. That is a fairly explicit statement that horizontal scale and datastore choice are first-class concerns. OpenFGA's own deployment story is a separate question that this repository cannot answer, and readers comparing the two should evaluate each project's own documentation rather than treating them as interchangeable.

The comparison against a relational database is more interesting, because it is the one teams actually make. A permissions table in Postgres can express direct grants cheaply, and for a single application with flat roles it is the simpler answer. What it handles badly is transitive membership: groups inside groups, folders inside folders, and the reverse question of everything a subject can reach. Answering those in SQL means recursive queries whose cost grows with graph depth, and every service writing its own version of the query. SpiceDB's value proposition is that the traversal is the product. If your permission graph is shallow and your services are few, that proposition does not pay for itself.

Install paths, licensing and the cost of upgrades

SpiceDB is licensed under Apache-2.0, with a NOTICE file in the repository root alongside LICENSE. Apache-2.0 permits commercial use and modification and includes an explicit patent grant. It does not, on its own, settle questions about the separate commercial offerings from AuthZed, and nothing here is legal advice: if you are evaluating the hosted product and the open source database together, read the terms for each.

The project is not archived, and the last push to the default branch was on 2026-09-21. Releases are frequent: v1.56.0 on 2026-07-24, v1.56.1 on 2026-08-26, and v1.56.2 on 2026-09-11. That cadence is the upgrade cost. A patch release every few weeks means you need a policy for when to move, and the migration container in the compose file is the mechanism you will exercise: the datastore migrate head command is what advances your datastore schema, and it runs before the server starts.

Two practical notes from the repository. First, the Dockerfile pins base images by digest and sets CGO_ENABLED=0 with a memoryprotection build tag; the comment references a linker flag workaround, which tells you the build is tuned for a static, small runtime image rather than for local hacking. Second, there is a TELEMETRY.md at the repository root, so read it before deploying if your organization has opinions about outbound reporting. The README does not document a rollback procedure for schema migrations, so plan upgrade and rollback as an operational question you answer yourself.

Editorial conclusion

Adopt SpiceDB if you have outgrown role checks scattered across services and want one place to answer "can subject X perform action Y on resource Z", with a schema you can validate before it reaches production. Do not adopt it if you need a graphical admin console or want authorization logic embedded in your application process; SpiceDB is a separate service with its own datastore to operate. Before committing, verify three things: that your target datastore is one of the engines covered by the repository's compose files, that your language has a client in the authzed ecosystem, and that your team accepts advancing your datastore through the spicedb datastore migrate command rather than editing tables by hand.

Frequently asked questions

Official sources

1. authzed/spicedb on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases