We Rewrote Openfga in Pure Postgres
Posted2 months agoActive2 months ago
getrover.substack.comTechstory
calmmixed
Debate
40/100
Authorization SystemsPostgresDatabase Design
Key topics
Authorization Systems
Postgres
Database Design
The author rewrote OpenFGA in pure Postgres, sparking a discussion on the trade-offs of storing logic in the database and the challenges of implementing authorization systems.
Snapshot generated from the HN discussion
Discussion Activity
Moderate engagementFirst comment
55m
Peak period
9
2-4h
Avg / period
3.5
Comment distribution14 data points
Loading chart...
Based on 14 loaded comments
Key moments
- 01Story posted
Oct 21, 2025 at 4:52 PM EDT
2 months ago
Step 01 - 02First comment
Oct 21, 2025 at 5:47 PM EDT
55m after posting
Step 02 - 03Peak activity
9 comments in 2-4h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 22, 2025 at 6:29 PM EDT
2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45661547Type: storyLast synced: 11/20/2025, 12:59:45 PM
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.
We should develop and translate this extension to other databases.
It’s cool that you’ve done this before. Did you face any performance bottlenecks when you’re post-filtering the results? I wonder if splitting it out into separate services would help keep things tidy or just add to the complexity.
This also makes me think about how often auth requirements change in agile environments. Like, do we even realize how quickly we need to adapt our models? Seems like a good moment to examine the tooling we use, especially if we could create an extension for other databases. The more I think about it, the more I see a push for this kind of flexibility in many applications.
Yep, as I mentioned above, its not an easy problem but once it is solved for you, it becomes "just" watching the events and performing the JOINs.
> especially if we could create an extension for other databases
See my video I linked above about the Postgres FDW: It does exactly this for SpiceDB and works seamlessly as-if there is a denormalized permissions table sitting in your Postgres, while still supporting the full array of complex authorization rules found in ReBAC.
Do you mean literally users to permissions?
Usually users map into groups, groups are subgroups of each other, and permissions are granted to groups.
So you can only see the financial data if you're in financial-report-preparers. Can Bob see the report? That depends on if he's an indirect or direct member of financial-report-preparers.
This is different from RBAC where Bob might have an admin or manager role directly. If he has admin access it's because he's a member of a certain group of employees that's a subgroup of another group of employees who all have admin access etc. similarly for groups of end users.
It would be a combinatorial explosion to try to enumerate the permissions of a given user. If people are having lot of syncing problems they may not have granular enough groups.
Groups make it safe. Groups are best.
However, as you mentioned, life is easier when the main database can handle everything, so we actually built a solution in that space called Materialize [2], which heavily denormalizes the authorization data and allows for joining within application databases such as Postgres. My colleague Evan actually put together a really cool video about using it with Gitea [3].
Recognizing that even with Materialize, however, the need to consume events can be a bit annoying, I've been doing some work to allow Postgres itself to do native JOINs against SpiceDB (and other operations). I demo it briefly in our recent announcements video [4] and I think it effectively solves this problem within Postgres, while still allowing for all the benefits (scale, performance, redundancy, distribution) of externalized authz.
[1]: https://authzed.com/docs/spicedb/modeling/protecting-a-list-...
[2]: https://authzed.com/products/authzed-materialize
[3]: https://www.youtube.com/live/u3i1SEd9Ll8?si=mCz5mZterxthoEwj
[4]: https://www.youtube.com/live/uz_gxz3whS0?si=g4NUZAIltYVyFzYj...
Disclaimer: I'm cofounder and CTO at AuthZed and we build SpiceDB and Materialize
This is a fundamental problem with all Zanzibar-inspired authorization systems[0] that require centralizing ~all authorization data and led us @ Oso to build a more flexible system[1] that grants more control over what authorization-relevant data you centralize vs. decide keep locally.
0: https://www.osohq.com/post/authorization-for-the-rest-of-us
1: https://www.osohq.com/docs/develop/facts/local-authorization
disclosure: founding engineer at Oso