JSjschorr·Dec 9, 2022
If you're curious to see a Postgres-based implementation, SpiceDB has a Postgres driver: https://github.com/authzed/spicedb/tree/main/internal/datast...
In Google Zanzibar Through Our Eyesauthzed
spicedb
Go2021–2026
authzed / spicedb
spicedb
Open Source, Google Zanzibar-inspired database for scalably storing and querying fine-grained authorization data
10Distinct people
45Mentions
0Explicit recommenders
7.2KGitHub stars
What to know before exploring
What it is
Open Source, Google Zanzibar-inspired database for scalably storing and querying fine-grained authorization data
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- permify/permify · linked in 3 of the same discussions
- ory/keto · linked in 2 of the same discussions
- warrant-dev/warrant · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 2:59:58 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year45 dated mentions
Observed mentions: 2021-09-30 14:56:32 UTC to 2026-07-26 18:02:44 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 27 | 2 | 25 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 11 | 0 | 11 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 2 | 0 | 2 |
What Hacker News says
27 sourcesYep! Groups can be easily nested under one another by simply creating a relationship between the group's members and the members of another group.
In SpiceDB [0] schema this can be represented like so:
definition group {
relation member: user | group#member
}
Here `member` allows a relationship to itself, which allows writing a relationship saying that every member of one group is a member of the containing group.
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
In Google Zanzibar Through Our EyesDistributed authorization is indeed hard! IAM is one of the few (maybe the only) AWS service that isn't regional and it's because permissions must propagate globally for correctness' sake. As a distributed systems junkie, I'm shocked that other folks aren't as interested in authorization systems because they really push the boundaries of what we can do with data consistency at scale.
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
Read the rest
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.
[0]: https://github.com/authzed/spicedb
The problem is that no one hierarchy fits every org. Sideways relationships that cross hierarchies exist, other exceptions exist.
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.
https://github.com/authzed/spicedb
In AWS IAM Roles, a tale of unnecessary complexityAwesome to hear more about MySQL/Vitess connection pooling.
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
[1]: https://github.com/jackc/pgx
[2]: https://github.com/planetscale/vtprotobuf
In One Million Database Connections> neither of the solutions you called out has been out for more than ~1 year,
That's a good callout. These are still early days when it comes to Zanzibar & co, and all implementations are very new. I'm glad different implementations exist. This will allow the community to experiment with multiple ideas and allow them to flourish or be discarded.
Authzed's idea Jimmy linked to elsewhere (Caveats) [0] is not in the Zanzibar paper, however it is an interesting option to try to tackle ABAC scenarios within a Zanzibar context.
OSO (and Aserto seems to be doing the same) is approaching this the other way - they have a good Policy/ABAC solution, do they benefit from a more Zanzibar-like approach to the AuthZ problem, the answer seems to be also yes (OSO Cloud [1]).
In OpenFGA, we dropped the concept of Zookies. Will we regret this? Time will tel
Read the rest
l. SpiceDB bet on the importance of Zookies, and in some cases they are right. We also added support for having multiple model versions active at the same time and some ABAC scenarios through Contextual Tuples [2] (less powerful than caveats, but more Zanzibar-y). Is that a good idea? Hopefully!
That's the beauty of it, there are considerations (pros and cons) for all of these approaches, users can pick and choose what works best for their situations. We will all learn and adapt. We may all end up discarding some of our assumptions and adopting new ones. Ultimately this will benefit all of us, and more importantly the wider audience and the ecosystem. And maybe newcomers will implement all of the good ideas floating around while discarding the cruft existing solutions are stuck with.
Hopefully as the ecosystem matures, all the implementations benefit from it. Multiple implementations allows each to investigate certain solutions.
Quoting Jimmy above:
> it'd be awesome to collaborate [...] this is what open source is all about
100%! Though as a FOSS fan myself, I'm hoping for a new comer GPL/copyleft solution to come about and rule us all :)
Side-note: Absolutely loved this article from OSO with Abhishek Parmar, one of the co-creators of Zanzibar [3]
[0]: https://github.com/authzed/spicedb/issues/386
[1]: https://www.osohq.com/docs/concepts/oso-cloud-data-model
[2]: https://openfga.dev/docs/modeling/contextual-time-based-auth...
[3]: https://www.osohq.com/post/abhishek-parmar-oso
[Disclaimer: On the OpenFGA team]
Love the growing number of OSS Zanzibar implementations, and congrats to the Aserto team for launching Topaz!
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]
In Show HN: Topaz: open-source authorization combining the best of OPA and ZanzibarUnless you are building a database, these embedded KV store libraries are less likely to be the best solution the job. If you are considering them for an app that isn't a database, you should also take a long, hard look at SQLite first.
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
Read the rest
optimized for querying access control data in a way that can coordinate with causality across multiple services.
[0]: https://github.com/vitessio/vitess
[1]: https://github.com/authzed/spicedb
This might just be a language issue, because different sources use different words for consistency guarantees.
> 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 consiste
Read the rest
ncy 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/...
[1]: https://github.com/authzed/spicedb
[2]: https://authzed.com/blog/prevent-newenemy-cockroachdb/
Like many other folks like the founders of CockroachDB and CoreOS, we read a Google research paper posted to HN.
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.
[0]: https://github.com/authzed/spicedb
In Ask HN: What HN post made you money?Congrats on the launch!
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.
[0]: https://github.com/authzed/spicedb
In EdgeDB 2.0This is why 1 year ago we open sourced[0] SpiceDB[1] under Apache2 and have been leading the way for open source Zanzibar systems. SpiceDB has contributors and users from the likes of GitHub and Adobe in addition to Authzed; building in the open and making sure that we aren't the only ones supporting SpiceDB is critical to the long term success of our users and our business.
[0]: https://twitter.com/authzed/status/1443590501484032002
[1]: https://github.com/authzed/spicedb
In Launch HN: Warrant (YC S21) – Authorization and access control as a serviceAs the developer of an external authorization system (full disclosure)[0], I feel obligated to chime in the critiques of external authorization systems in this article. I don't think they're far off base, as we do recommend RLS for use cases like what the article covers, but anyways, here's my two cents:
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
Read the rest
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...
[2]: https://docs.authzed.com/guides/schema
The problem you're describing is sometimes called the "ACL Aware Indexing" problem [1]. In a permissions service based on Zanzibar, this can partially be solved by walking the permissions graph in a reverse fashion: SpiceDB exposes this API as the LookupResource API [2]. However, even this approach has performance implications for very large datasets, so we're also working on improving resource lookup via a LookupWatch API [3], which can be used by consumers to actively cache the available set of resources as access changes over time.
[1]: https://authzed.com/blog/acl-filtering-in-authzed/
[2]: https://buf.build/authzed/api/docs/main:authzed.api.v1#authz...
[3]: https://github.com/authzed/spicedb/issues/207
In Show HN: Permify – Open-source authorization service based on Google ZanzibarSpiceDB: Production-ready permissions database inspired by Google Zanzibar
1 points · Open discussionShowing the 15 most recent of 27 sources. Enable JavaScript to search and browse every indexed mention.