spicedb
Open Source, Google Zanzibar-inspired database for scalably storing and querying fine-grained authorization data
Top Related Projects
The most scalable and customizable permission server on the market. Fix your slow or broken permission system with Google's proven "Zanzibar" approach. Supports ACL, RBAC, and more. Written in Go, cloud native, headless, API-first. Available as a service on Ory Network and for self-hosters.
An authorization library that supports access control models like ACL, RBAC, ABAC in Golang: https://discord.gg/S5UjpzGZjN
Open Policy Agent (OPA) is an open source, general-purpose policy engine.
Deprecated: See README
Warrant is a highly scalable, centralized authorization service based on Google Zanzibar. Use it to define, enforce, query, and audit application authorization and access control.
An open-source authorization as a service inspired by Google Zanzibar, designed to build and manage fine-grained and scalable authorization systems for any application.
Quick Overview
SpiceDB is an open-source, Google Zanzibar-inspired database system for managing application permissions. It provides a flexible, scalable, and performant solution for implementing fine-grained authorization in modern applications, allowing developers to define and enforce complex access control policies.
Pros
- Implements the battle-tested Google Zanzibar model for authorization
- Highly scalable and performant, suitable for large-scale applications
- Provides a flexible schema language for defining relationships and permissions
- Offers client libraries in multiple programming languages
Cons
- Steep learning curve for developers unfamiliar with relationship-based authorization
- Requires additional infrastructure setup compared to simpler authorization methods
- May be overkill for small applications with simple permission requirements
- Limited ecosystem and community support compared to more established solutions
Code Examples
- Defining a schema:
definition user {}
definition document {
relation viewer: user
relation editor: user
relation owner: user
permission view = viewer + editor + owner
permission edit = editor + owner
permission delete = owner
}
- Checking permissions:
allowed, err := client.CheckPermission(ctx, &v1.CheckPermissionRequest{
Resource: &v1.ObjectReference{
ObjectType: "document",
ObjectId: "doc1",
},
Permission: "view",
Subject: &v1.SubjectReference{
Object: &v1.ObjectReference{
ObjectType: "user",
ObjectId: "user1",
},
},
})
- Writing relationships:
_, err := client.WriteRelationships(ctx, &v1.WriteRelationshipsRequest{
Updates: []*v1.RelationshipUpdate{
{
Operation: v1.RelationshipUpdate_OPERATION_CREATE,
Relationship: &v1.Relationship{
Resource: &v1.ObjectReference{
ObjectType: "document",
ObjectId: "doc1",
},
Relation: "viewer",
Subject: &v1.SubjectReference{
Object: &v1.ObjectReference{
ObjectType: "user",
ObjectId: "user1",
},
},
},
},
},
})
Getting Started
-
Install SpiceDB:
docker pull authzed/spicedb
-
Run SpiceDB:
docker run -p 50051:50051 authzed/spicedb serve --grpc-preshared-key "somerandomkey"
-
Install a client library (e.g., Go):
go get github.com/authzed/authzed-go
-
Connect to SpiceDB and start using it in your application:
import ( "github.com/authzed/authzed-go/v1" "github.com/authzed/authzed-go/v1/client" ) c, err := client.NewClient( "localhost:50051", client.WithInsecure(), client.WithPresharedKey("somerandomkey"), )
Competitor Comparisons
The most scalable and customizable permission server on the market. Fix your slow or broken permission system with Google's proven "Zanzibar" approach. Supports ACL, RBAC, and more. Written in Go, cloud native, headless, API-first. Available as a service on Ory Network and for self-hosters.
Pros of Keto
- More extensive documentation and guides
- Broader ecosystem integration with other Ory projects
- Supports multiple storage backends (SQL, in-memory)
Cons of Keto
- Less focus on performance optimization
- More complex setup and configuration
- Limited built-in support for fine-grained permissions
Code Comparison
SpiceDB uses a custom DSL for defining relationships:
definition user {}
definition document {
relation viewer: user
relation editor: user
permission view = viewer + editor
}
Keto uses JSON for defining relationships:
{
"namespace": "documents",
"object": "file",
"relation": "viewer",
"subject": "user:john"
}
Both SpiceDB and Keto are open-source authorization systems designed to handle complex permission models. SpiceDB focuses on high performance and scalability, using a custom DSL for defining relationships. It's well-suited for large-scale applications with complex permission structures.
Keto, part of the Ory ecosystem, offers broader integration possibilities and more extensive documentation. It uses a JSON-based format for defining relationships and supports multiple storage backends, making it flexible for various deployment scenarios.
While SpiceDB excels in performance and fine-grained permissions, Keto provides a more accessible setup process and better integration with other identity and access management tools in the Ory suite.
An authorization library that supports access control models like ACL, RBAC, ABAC in Golang: https://discord.gg/S5UjpzGZjN
Pros of Casbin
- More flexible and supports multiple access control models (ACL, RBAC, ABAC, etc.)
- Extensive language support with official adapters for 15+ programming languages
- Large and active community with frequent updates and contributions
Cons of Casbin
- Steeper learning curve due to its flexibility and multiple model support
- May require more configuration and setup for complex authorization scenarios
- Performance can be impacted when dealing with large-scale authorization checks
Code Comparison
Casbin:
e := casbin.NewEnforcer("model.conf", "policy.csv")
sub := "alice"
obj := "data1"
act := "read"
if allowed := e.Enforce(sub, obj, act); allowed {
// permit alice to read data1
}
SpiceDB:
client := spicedb.NewClient(...)
subject := zed.NewSubjectSet("user", "alice")
resource := zed.NewObjectSet("document", "data1")
permission := "read"
allowed, err := client.CheckPermission(ctx, subject, resource, permission)
if allowed {
// permit alice to read data1
}
Both examples demonstrate basic permission checking, but Casbin's approach is more compact and relies on a configuration file, while SpiceDB uses a client-server model with a more verbose API.
Open Policy Agent (OPA) is an open source, general-purpose policy engine.
Pros of OPA
- More flexible and general-purpose policy engine, suitable for a wide range of use cases beyond just authorization
- Larger community and ecosystem, with extensive documentation and integrations
- Declarative policy language (Rego) that's powerful and expressive
Cons of OPA
- Steeper learning curve due to the complexity of Rego and its broad scope
- Can be overkill for simpler authorization scenarios
- Performance may be slower for large-scale authorization checks compared to SpiceDB
Code Comparison
SpiceDB uses a schema-based approach with relationship tuples:
definition user {}
definition document {
relation viewer: user
permission view = viewer
}
OPA uses Rego for policy definition:
package authz
default allow = false
allow {
input.method == "GET"
input.path == ["documents", doc_id]
data.documents[doc_id].viewers[input.user]
}
Both systems offer powerful authorization capabilities, but SpiceDB is more focused on relationship-based access control, while OPA provides a more general-purpose policy engine that can be applied to various domains beyond authorization.
Deprecated: See README
Pros of Oso
- More flexible policy language (Polar) that supports complex rules and integrations
- Easier to integrate with existing application code and data models
- Provides libraries for multiple programming languages (Python, Ruby, Java, etc.)
Cons of Oso
- Potentially slower performance for large-scale authorization checks
- Less focus on distributed systems and high-throughput scenarios
- Requires more custom implementation for advanced features like audit logging
Code Comparison
Oso (Polar language):
allow(user, "read", post) if
user.role = "admin" or
post.author = user;
SpiceDB (Relationship tuples):
user:alice#admin
post:123#author@user:bob
post:123#viewer@user:alice
Summary
Oso offers a more flexible and developer-friendly approach to authorization, making it easier to integrate with existing applications. SpiceDB, on the other hand, focuses on high-performance, scalable authorization for distributed systems. The choice between the two depends on specific project requirements, such as scalability needs, integration complexity, and the desired level of customization in authorization rules.
Warrant is a highly scalable, centralized authorization service based on Google Zanzibar. Use it to define, enforce, query, and audit application authorization and access control.
Pros of Warrant
- Simpler setup and configuration process
- Built-in user management and authentication features
- Supports both API and SDK integration options
Cons of Warrant
- Less mature project with fewer contributors
- Limited documentation compared to SpiceDB
- Fewer advanced features for complex authorization scenarios
Code Comparison
SpiceDB schema definition:
definition user {}
definition resource {
relation viewer: user
permission view = viewer
}
Warrant permission definition:
{
"objectType": "resource",
"relation": "viewer",
"subject": {
"objectType": "user",
"objectId": "user123"
}
}
Both projects aim to provide fine-grained authorization solutions, but they differ in their approach and feature set. SpiceDB focuses on a more flexible and powerful authorization model, while Warrant offers a simpler setup with built-in user management. SpiceDB uses a custom schema language for defining relationships, whereas Warrant uses JSON for permission definitions. SpiceDB may be better suited for complex, large-scale applications, while Warrant could be a good choice for smaller projects or those requiring quick integration of both authentication and authorization.
An open-source authorization as a service inspired by Google Zanzibar, designed to build and manage fine-grained and scalable authorization systems for any application.
Pros of Permify
- More flexible schema definition with support for custom types and relations
- Built-in support for multi-tenancy and data isolation
- Easier integration with existing databases and data models
Cons of Permify
- Less mature project with fewer production deployments
- Smaller community and ecosystem compared to SpiceDB
- Limited documentation and examples for advanced use cases
Code Comparison
Permify schema definition:
entity:
user:
relations:
manager: user
document:
relations:
owner: user
viewer: user
SpiceDB schema definition:
definition user {}
definition document {
relation viewer: user
relation owner: user
permission view = viewer + owner
permission edit = owner
}
Both Permify and SpiceDB provide declarative ways to define authorization models, but Permify's schema is more flexible and allows for custom entity types. SpiceDB's schema is more concise and includes built-in permission definitions.
Permify offers a more adaptable approach for complex authorization scenarios, while SpiceDB provides a more opinionated and streamlined experience. The choice between the two depends on specific project requirements, existing infrastructure, and desired level of customization.
Convert
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
SpiceDB sets the standard for authorization that scales.
Scale with
Traffic ⢠Dev Velocity ⢠Functionality ⢠Geography
What is SpiceDB?
SpiceDB is the most mature open source project inspired by Google's internal authorization system: Zanzibar.
As of 2021, broken access control became the #1 threat to web security according to OWASP. With SpiceDB, platform and product teams can be be protected by answering this question easily: "can subject X perform action Y on resource Z?"
Similar to a relational database, developers define a schema, write data in the form of relationships, and then use SpiceDB's clients to issue permission checks in their application to determine what actions a user can take on a resource. Other queries are also possible, such as "What can subject
do?" or "Who can access resource
?".
SpiceDB is often ran as a centralized service shared across product suites and microservice architectures.
SpiceDB is focused purely on authorization and is designed to be fully agnostic to authentication solutions/identity providers.
What is Google Zanzibar?
In 2019, Google released the paper "Zanzibar: Google's Consistent, Global Authorization System" providing the original inspiration for SpiceDB. The paper presents the design, implementation, and deployment of, Zanzibar, Google's internal system for storing and evaluating access control lists. Originally designed for Google+ Circles, Zanzibar now sits at the core Google's entire product suite (Calendar, Drive, Maps, Photos, YouTube) and powers the Google Cloud IAM service.
While SpiceDB has gone on to innovate well beyond the functionality outlined in the paper, development of SpiceDB aims to always remain faithful to the paper's values and goals.
Why SpiceDB?
- World-class engineering: painstakingly built by experts that pioneered the cloud-native ecosystem
- Authentic design: mature and feature-complete implementation of Google's Zanzibar paper
- Proven in production: 5ms p95 when scaled to millions of queries/s, billions of relationships
- Global consistency: consistency configured per-request unlocks correctness while maintaining performance
- Multi-paradigm: caveated relationships combine the best concepts in authorization: ABAC & ReBAC
- Safety in tooling: designs schemas with real-time validation or validate in your CI/CD workflow
- Reverse Indexes: queries for "What can
subject
do?", "Who can accessresource
?"
Who uses SpiceDB?
SpiceDB is a powerful tool in a variety of domains and in organizations of all sizes; we've chosen to highlight a few interesting community members:
- IBM's AI Data & Model Factory Platform
- Red Hat's Insights Platform
- GitPod
- TubiTV China (䏿)
- DMM Online Salon (æ¥æ¬èª)
Beyond the community, you can also read customer stories for commercial usage of SpiceDB.
Getting Started
Installing the binary
Binary releases are available for Linux, macOS, and Windows on AMD64 and ARM64 architectures.
Homebrew users for both macOS and Linux can install the latest binary releases of SpiceDB and zed using the official tap:
brew install authzed/tap/spicedb authzed/tap/zed
Debian-based Linux users can install SpiceDB packages by adding a new APT source:
sudo apt update && sudo apt install -y curl ca-certificates gpg
curl https://pkg.authzed.com/apt/gpg.key | sudo apt-key add -
sudo echo "deb https://pkg.authzed.com/apt/ * *" > /etc/apt/sources.list.d/fury.list
sudo apt update && sudo apt install -y spicedb zed
RPM-based Linux users can install SpiceDB packages by adding a new YUM repository:
sudo cat << EOF >> /etc/yum.repos.d/Authzed-Fury.repo
[authzed-fury]
name=AuthZed Fury Repository
baseurl=https://pkg.authzed.com/yum/
enabled=1
gpgcheck=0
EOF
sudo dnf install -y spicedb zed
Running a container
Container images are available for AMD64 and ARM64 architectures on the following registries:
Docker users can run the latest SpiceDB container with the following:
# expose grpc and http. http is used in the examples below.
docker run --rm -p 50051:50051 -p 8443:8443 authzed/spicedb serve --http-enabled true --grpc-preshared-key "somerandomkeyhere"
SpiceDB containers use Chainguard Images to ship the bare minimum userspace which is a huge boon to security, but can complicate debugging. If you want to execute a user session into a running SpiceDB container and install packages, you can use one of our debug images.
Appending -debug
to any tag will provide you an image that has a userspace with debug tooling:
docker run --rm -ti --entrypoint sh authzed/spicedb:latest-debug
Containers are also available for each git commit to the main
branch under ${REGISTRY}/authzed/spicedb-git:${COMMIT}
.
Write your own schema and relationships
Now that you have SpiceDB running, you must define your schema and write relationships that represent the permissions in your application. There are various way to do this:
- Use the client libraries.
- Use the hosted Playground or run it yourself locally. The playground contains a set of example schemas and test data for different scenarios.
- Use the zed CLI.
- Use the gRPC or the HTTP APIs. For example:
# write a schema
curl --location 'http://localhost:8443/v1/schema/write' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--header 'Authorization: Bearer somerandomkeyhere' \
--data '{
"schema": "definition user {} \n definition folder { \n relation parent: folder\n relation viewer: user \n permission view = viewer + parent->view \n } \n definition document {\n relation folder: folder \n relation viewer: user \n permission view = viewer + folder->view \n }"
}'
# write a relationship
curl --location 'http://localhost:8443/v1/relationships/write' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--header 'Authorization: Bearer somerandomkeyhere' \
--data '{
"updates": [
{
"operation": "OPERATION_TOUCH",
"relationship": {
"resource": {
"objectType": "folder",
"objectId": "budget"
},
"relation": "viewer",
"subject": {
"object": {
"objectType": "user",
"objectId": "anne"
}
}
}
}
]
}'
You can follow a guide for developing a schema or review the the schema language design documentation.
Finally, you can watch the SpiceDB primer video on schema development.
Query the SpiceDB API
You can use the client libraries or the gRPC and HTTP APIs to query SpiceDB. For example,
curl --location 'http://localhost:8443/v1/permissions/check' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--header 'Authorization: Bearer somerandomkeyhere' \
--data '{
"consistency": {
"minimizeLatency": true
},
"resource": {
"objectType": "folder",
"objectId": "budget"
},
"permission": "view",
"subject": {
"object": {
"objectType": "user",
"objectId": "anne"
}
}
}'
#{
# "checkedAt": {
# "token": "GhUKEzE3NTE1NjYwMjUwMDAwMDAwMDA="
# },
# "permissionship": "PERMISSIONSHIP_HAS_PERMISSION"
#}
'
You can also issue queries with zed, the official command-line client.
The Playground also has a tab for experimenting with zed
all from within your browser.
Integrating SpiceDB into Your Application
To get an understanding of integrating an application with SpiceDB, you can follow the Protecting Your First App guide or review API documentation on the Buf Registry or Postman.
Deploying to Production
The core SpiceDB service has been utilized in production by Authzed since 2021 so you can be confident that it is battle-tested. Moreover, it supports various datastores, including Google Cloud Spanner, CockroachDB, MySQL, and PostgreSQL. Read this to learn the best practices for each.
You can choose to self-host SpiceDB, or use AuthZed Cloud, a fully managed service. See a comparison of the various options.
If you choose to self-host, we recommend deploying SpiceDB using Kubernetes. If you're only experimenting, feel free to try out one of our community-maintained examples for testing SpiceDB on Kubernetes:
kubectl apply -f https://raw.githubusercontent.com/authzed/examples/main/kubernetes/example.yaml
For a more detailed guide on the SpiceDB Kubernetes Operator, see this.
For more best practices on deploying SpiceDB, read our best practices guide.
Telemetry
SpiceDB collects anonymous telemetry data to help us understand how the community is using SpiceDB and to help us prioritize features. This telemetry is opt-out and can be disabled via setting --telemetry-endpoint=""
. For more information on the telemetry we collect, see telemetry.
More Resources
- Ask questions via GitHub Discussions or our Community Discord
- Read blog posts from the Authzed team describing the project and major announcements
- Follow our self-guided workshops on usecases ranging from Updating Web Views, to Securing RAG Pipelines
- Watch our YouTube videos about SpiceDB, modeling schemas, leveraging CNCF projects, and more
- Explore the SpiceDB Awesome List that enumerates official and third-party projects built by the community
- Reference community examples for demo environments, integration testing, CI pipelines, and writing schemas
Join the Community
Join our fellow contributors from companies such as GitHub,
Adobe,
Google,
Fastly,
Plaid,
Red Hat, and
Reddit.
SpiceDB is a community project where everyone is invited to participate and feel welcomed. While the project has a technical goal, participation is not restricted to those with code contributions.
CONTRIBUTING.md documents communication, contribution flow, legal requirements, and common tasks when contributing to the project.
You can find issues by priority: Urgent, High, Medium, Low, Maybe. There are also good first issues.
Our documentation is also open source if you'd like to clarify anything you find confusing.
Acknowledgements
SpiceDB is a community project fueled by contributions from both organizations and individuals. We appreciate all contributions, large and small, and would like to thank all those involved.
In addition, we'd like to highlight a few notable contributions:
The GitHub Authorization Team for implementing and contributing the MySQL datastore
The Netflix Authorization Team for sponsoring and being a design partner for caveats
The Equinix Metal Team for sponsoring our benchmarking hardware
Top Related Projects
The most scalable and customizable permission server on the market. Fix your slow or broken permission system with Google's proven "Zanzibar" approach. Supports ACL, RBAC, and more. Written in Go, cloud native, headless, API-first. Available as a service on Ory Network and for self-hosters.
An authorization library that supports access control models like ACL, RBAC, ABAC in Golang: https://discord.gg/S5UjpzGZjN
Open Policy Agent (OPA) is an open source, general-purpose policy engine.
Deprecated: See README
Warrant is a highly scalable, centralized authorization service based on Google Zanzibar. Use it to define, enforce, query, and audit application authorization and access control.
An open-source authorization as a service inspired by Google Zanzibar, designed to build and manage fine-grained and scalable authorization systems for any application.
Convert
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot