Permission Systems for Enterprise That Scale
Key topics
Diving into the complexities of permission systems for enterprises, commenters are weighing in on the best approaches to scaling these systems. Some are touting the Postgres ltree module as a game-changer for permission systems, particularly for file structure use-cases, while others are questioning its advantages over alternative solutions. The discussion also touches on the potential pitfalls of pre-computed permissions, with the author clarifying that while databases are ACID compliant, synchronization isn't enforced out of the box, requiring careful transaction management. As one commenter is about to embark on a similar project, the conversation is sparking valuable insights and practical advice.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
1h
Peak period
17
0-6h
Avg / period
5.1
Based on 36 loaded comments
Key moments
- 01Story posted
Dec 24, 2025 at 4:50 AM EST
10 days ago
Step 01 - 02First comment
Dec 24, 2025 at 6:14 AM EST
1h after posting
Step 02 - 03Peak activity
17 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 27, 2025 at 12:18 PM EST
6d ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
>The main risk with pre-computed permissions is data getting out of sync.
It would make sense to have permissions be a first class concept for databases and to ensure such a desync could never happen. Data being only read or written from specific users is a very common thing for data so it would be worth having first class support for it.
Much more likely I think is that you can’t use the db to prevent invalid states here (unique constraint, etc) and you’re dependent on other areas of the code correctly implementing concurrency controls. Race condition in resource A causes problems in your permissions table now.
And just from a general engineering perspective, you should assume things are going to fail and assess what your path forward looks like when they do. Recovery script sounds like a good idea for a critical area.
One of the major benefits of a centralized authorization system is allowing for permissions queries across resources and subjects from multiple different services/sources (of course, with the need to synchronize the data in)
Happy to expand on how some users do so, if you're curious.
We have a guide on doing ACL-aware filtering and listing [2] with this API and describing other approaches for larger Enterprise scales
Disclaimer: I'm the co-founder and CTO of AuthZed, we develop SpiceDB, and I wrote our most recent implementation of LookupResources
[1]: https://buf.build/authzed/api/docs/main:authzed.api.v1#authz... [2]: https://authzed.com/docs/spicedb/modeling/protecting-a-list-...
However, some deeply recursive or wide relations can still be slow, so Zanzibar also has a pre-computation cache called Leopard that is used for a very specific subset of these relations [2]. For SpiceDB, we called our version of this cache Materialize and it is designed expressly for handling "Enterprise" levels of scale in a similar fashion, as sometimes it is simply too slow to walk these deep graphs in real-time.
[1]: https://zanzibar.tech/24uQOiQnVi:1T:4S [2]: https://zanzibar.tech/21tieegnDR:0.H1AowI3SG:2O
[1]: https://discord.com/invite/GBeT3R4k84
Fine-grained authorization as an incremental computation problem
And that it is an internal google system?
Scales both on the tech, and on the human side - e.g. your product manager can add roles (with CI approval) without requiring engineering involvement.
(I'm biased but still true)
https://www.permit.io/rebac
Trees with RDBMSes do stay a pain, though :-)
The downside to this approach is that it requires some planning and to maintain in code what mask retrieves what permission(s).