What does HackerNews think of spicedb?
Open source fine-grained permissions database inspired by Google Zanzibar
The UX definitely isn't optimized for Supabase, but I'd love to learn more about how that could be improved. I suspect it might be complicated if Supabase assumes RLS for everything.
Full disclosure, I think about this topic regularly because I am a maintainer of SpiceDB[1], an open source authorization database.
It's a little silly, but lots of folks aim for the moon when it comes to performance for authorization, but then go on and sprinkle a dozen feature-flag RPCs each adding more and more latency. You should be able to keep feature-flags performant, too: that's why some SpiceDB users collapse checking for authorization and feature-flags into a single round-trip by defining a permission also requires a feature-flag (e.g. permission = admin & has_beta_feature).
It's really encouraging to be working in this space because there are so many epiphanies like the one in the article, but there just hasn't been tooling to make it as obvious until now. We're seeing folks adopt SpiceDB for update graphs and dependency graphs because the resolution of permissions (finding a path through a graph) is similar to solving these problems as well!
Disclaimer: I am the cofounder of AuthZed, where we are building an open source version of Zanzibar known as SpiceDB [2]
[1] https://zanzibar.tech [2] https://github.com/authzed/spicedb
In SpiceDB [0] schema this can be represented like so:
definition group {
relation member: user | group#member
}
I threw together an example in our playground [1], if you'd like to try it out!
[0]: https://github.com/authzed/spicedb [1]: https://play.authzed.com/s/9D5h9I7mE9mK/schema
It's unfortunate that only Amazon themselves can add new permissions to IAM to secure their services. Why can't our applications add new permissions to IAM and query those? This is going to be a shameless plug, but it was this very problem that caused my cofounders and I to quit our jobs and start a company. Together (and now with a community of hundreds of users and contributions from a few well-known companies) we built SpiceDB[0], which is the culmination of state of the art distributed systems and authorization technology developed open source instead of behind closed doors at a hyper-scaler. We were mostly inspired by the internal system at Google, which is actually more powerful than AWS or Google Cloud's IAM services, despite a fork of it actually powering GCP's IAM.
I find directed-graph-based approach in spicedb to be a better primitive than hierarchy with weird exceptions.
Directed edges are a much easier way to think about relationships even if they are logically equivalent to hierarchies.
Folks typically only consider memory usage for database connections, but we've also had to consider the p99 latency for establishing a connection. For SpiceDB[0] one place we've struggled for our MySQL backend (originally contributed by GitHub who are big Vitess users) is preemptively establishing connections in the pool so that it's always full. PGX[1] has been fantastic for Postgres and CockroachDB, but I haven't found something with enough control for MySQL.
PS: Lots of love to to all my friends at Planetscale! SpiceDB is also a big user of vtprotobuf[2] -- a great contribution to the Go gRPC ecosystem.
[0]: https://github.com/authzed/spicedb
Ory Keto's intro video @ SV IAM User Group [0] is worth a watch.
Other OSS Zanzibar implementations:
- https://github.com/authzed/spicedb
- https://github.com/Permify/permify
- https://github.com/openfga/openfga
[0]: https://www.youtube.com/watch?v=3vtTFLB_jDo
[Disclaimer: On the OpenFGA team]
What's also interesting is the trend of newer distributed "database systems" like Vitess[0] or SpiceDB[1] that forego embedded KV stores and instead reuse existing SQL databases as their "embedded database". Vitess leverages MySQL and SpiceDB leverages MySQL, PostgreSQL, CockroachDB, or Spanner. Systems built this way get to leverage many high-level features from existing databases systems such that they can focus on innovating in even higher-level functionality. In the case of Vitess, it's scaling, distributing, and schema management of MySQL. In the case of SpiceDB, it's building a database specifically optimized for querying access control data in a way that can coordinate with causality across multiple services.
> Accord only avoids enforcing an ordering (2) on transactions that are commutative
If the committed state in the database records the transactions in a different order than an external observer could have observed them being accepted by the database, then you don't have what Spanner calls "external consistency" - I thought this is what you mean when you say "global strict serializability", but now I'm not so sure.
Cockroach does enforce this property, but only for transactions that touch the same (key-value layer) keys. They talk about this a bit in their article on "life without atomic clocks"[0].
In SpiceDB[1], we take advantage of this property (when Cockroach is selected as the backing datastore) to give us external consistency by forcing all transactions to overlap. This prevents the New Enemy Problem[2], which is what Google calls the problem of transaction ordering when seen from an authorization perspective.
Your description of Accord sounded very similar to how Cockroach works from this perspective, but there may be some subtlety that I am missing. Cockroach exposes snapshots via "as of system time" queries, which can expose "bad" ordering back to the client in future queries - if Accord doesn't allow snapshot queries then I suppose it wouldn't be an issue.
[0]: https://cockroachlabs.com/blog/living-without-atomic-clocks/...
I think this is the original post: https://news.ycombinator.com/item?id=20132520
We left Red Hat a year later and joined YC to start a company based on the Zanzibar paper. Out of that, the open source SpiceDB[0] was born.
How do folks deal with the latency of not being able to run EdgeDB on the same server as their managed Postgres service (e.g. RDS)?
Full disclosure: I work on SpiceDB[0] which is a fine-grained permissions database. SpiceDB can also be backed by Postgres, but we form a distributed cache with our database instances so that trips to the datastore (e.g. Postgres) are avoided at all costs.
1+2: Cost + Unnecessary complexity: this argument can be used against anything that doesn't fit the given use case. There's no silver bullet for any choice of solution. You should only adopt the solution that makes the most sense for you and vendors should be candid about when they wouldn't recommend adopting their solution -- it'd be bad for both the users and reputation of the solution.
3: External dependencies: That depends on the toolchain. Integration testing against SpiceDB is easier than Postgres, IMO [1]. SpiceDB integration tests can run fully parallelized and can also model check your schema so that you're certain there are no flaws in your design. In practice, I haven't seen folks write tests to assert that their assumptions about RLS are maintained over time. The last place you want invariants to drift is authorization code.
4: Multi-tenancy is core to our product: I'm not sure I'm steel-manning this point, but I'll do my best. Most companies do not employ authorization experts and solutions worth their salt should support modeling multi-tenant use cases in a safe way. SpiceDB has a schema language with idioms and recommendations to implement functionality like multi-tenancy, but still leaves it in the hands of developers to construct the abstraction that matches their domain[2].
[0]: https://github.com/authzed/spicedb
[1]: https://github.com/authzed/examples/tree/main/integration-te...
- Ory came out first with Ory Keto ( https://github.com/ory/keto ) which is trying to be a close adaptation of the paper. Initially, many concepts were missing but they are making a lot of progress with the DSL and it interfaces with the rest of Ory (OAuth2, User Mangement)
- Authzed came out as a SaaS only, open sorucing the code base later on at https://github.com/authzed/spicedb
- Auth0 has been playing around with Zanzibar concepts in various forms and published a beta service at https://dashboard.fga.dev - apparently now also open source parts of it similar to what Authzed did: https://github.com/openfga
- Permify - who on a side note spammed me quite a lot with outreach because I was active in these communities - joins as well https://github.com/Permify/permify
It's exciting to see so much movement, yet also sad that so many companies are brewing their own beer instead of working collaborative on the more succesful projects. Feels like we'll just end up with one or two successful projects (looking at Ory / Auth0 here) with the rest perishing. I'm wondering if there truly is a business model for just this permission system as a saas service (looks like this is what everyone is going with). Here I'm giving Auth0 probably the biggest plus as they have an established identity service. Then again, Okta (parent of Auth0) and Auth0 themselves are not particularly known for good business practices that we usually expect from developer tooling.
What's refreshing though with Permify is that they are trying a bit of a different approach to Zanzibar!
The Authzed team[0] built Postgres syncing with the SpiceDB Postgres Connector[1] to explore syncing, but we never got it into a place that the community could agree upon. Users in the SpiceDB community are using technologies like CDC external to SpiceDB successfully, but there are many foot-guns to syncing because it can violate data consistency. Is there documentation on how Permify handles consistency (e.g. the Zookies/The New Enemy Problem from the Zanzibar paper)?
I use the following as my "rule of thumb": ReBAC databases want to have deterministic computation for your permissions. In the default case, this should be your ideal as well as it is the most understandable/scalable/testable/auditable/debuggable. But reality is that there will be places where you'll want _some_ non-determinism and in those scenarios it makes sense to leverage policy engines.
The SpiceDB community is exploring what it might take to support adding lightweight policies to the Zanzibar-like model to have the best of both worlds. If that sounds interesting, you can participate in the proposal[1].
> "How will additional microservices check permissions?"
SpiceDB is a database optimized for resolving subjects' access to resources. Being a database, it suggests storing the canonical authorization data within it and performing queries to it from various microservices. This is the strategy employed by most hyper-scalers and but also companies that have heavily invested in in-house authorization like like Airbnb and Carta.
> "How can we test and enforce that our authorization system is correct?"
SpiceDB has developers write schemas, but unlike other databases, it has tooling that can check assertions and audit all possible access. This tooling can be shared/explored via the Authzed Playground[1] or added to your CI/CD pipeline with GitHub Actions[2]
> "Can I support user-defined permissions?"
There are various ways to accomplish this with SpiceDB. User behavior can be used to pragmatically generate schemas or you can write very abstract schemas that push designs that are typically enforced at schema-validation/compile-time (think DDL) to runtime (think DML).