Strange the article proposes itself for "Enterprise" yet has no mention of Google's Zanzibar and how it compares to the other approaches. AFAIK it doesn't use pre-computed values but just queries really fast (using Spanner so there's that)
>We added a point of failure, as the permissions table can get out of sync with the actual data.
>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.
I'm struggling to understand what the issue that the author is getting at. The point of a database is that it's ACID compliant, wrap insets/updates/deletes in a transaction and no such drift would occur. What am I missing?
I don't think you are missing anything. I think he is just pointing out that technically nothing is enforcing this synchronization, so if someone forgets to wrap things in a transaction, it could get out of sync.
I just want to point out you have to take care about that, yes you can have a trigger or a transaction to make sure it happens but it isn't there out of the box
Strange the article proposes itself for "Enterprise" yet has no mention of Google's Zanzibar and how it compares to the other approaches. AFAIK it doesn't use pre-computed values but just queries really fast (using Spanner so there's that)
Can you let me know how would you for example query all accessible resources for a user using Google's Zanzibar?
Related: if anyone has a method of achieving this query against GCP resources I'd be keen to learn that as well.
And https://projects.eclipse.org/projects/technology.biscuit
https://docs.feldera.com/use_cases/fine_grained_authorizatio...
Fine-grained authorization as an incremental computation problem
How would you achieve fast list queries of accessible resources with this approach?
feldera has a way to run ad-hoc/list queries on materialized views. Alternatively, you can send the result somewhere where you can query it.
>We added a point of failure, as the permissions table can get out of sync with the actual data.
>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.
Lot of 'new' databases are basing their moat on this and sync engines. Eg: supabase, zero.dev, jazzdb, etc.
I'm struggling to understand what the issue that the author is getting at. The point of a database is that it's ACID compliant, wrap insets/updates/deletes in a transaction and no such drift would occur. What am I missing?
I don't think you are missing anything. I think he is just pointing out that technically nothing is enforcing this synchronization, so if someone forgets to wrap things in a transaction, it could get out of sync.
I just want to point out you have to take care about that, yes you can have a trigger or a transaction to make sure it happens but it isn't there out of the box
If you're using Postgres then using the ltree module is great for permission systems. Available in RDS too
Do you have an article about that?
Could you explain why this is great over alternatives?