ReBAC isn't the problem. The ReBAC tools I tried are.

Adriano Foschi — Tue, 11 Aug 2026 12:04:43 +0000

ReBAC (relationship-based access control) decides access based on how entities are connected to each other, rather than on a role attached to the user. Nowhere is it written that you can see that repository. You see it because a chain of relationships leads you there.

It's a model I like, and I want to say that up front, because what follows isn't a criticism of ReBAC. I spent a few weeks integrating OpenFGA into a prototype to use it properly: declarative model, sixteen test scenarios, a hundred and twenty assertions running offline in two seconds with no database and no application. It worked well. I removed it anyway.

Not because of a bug, and not because of check latency. I removed it because none of the tools I tried gives me a usable answer to the second question every application asks.

The check is fast. The list isn't.

"Can this user see this object?" resolves in milliseconds.

The problem is that the first screen after login is almost always a list. And "which objects can this user see?" looks like the same question reversed, but it isn't: nowhere is it recorded which objects are reachable, which is the point of ReBAC seen from the other side.

In the first case you hold two things and walk the graph from one to the other. In the second you hold only the user, and the set of possible answers is everything that exists in the system.

Three routes, and where each one stops

Filter afterwards. Normal query with its normal pagination, then you send the twenty-five ids to the service and drop the ones that don't pass. The result is correct, but the total at the bottom of the page is the one from before the filter, so it's a lie. And the user with access to a small slice gets three rows out of twenty-five.

Filter first. You ask the service which objects the user holds that permission on and hand them to the database. Except the list arrives whole. There's no real pagination to draw twenty-five from. It ends up as an IN with thousands of identifiers.

A local index. You build yourself a "user → what they can see" table and the filter goes back to being a JOIN. But to fill it you need the computed permissions, and the engine doesn't expose those: the API for following changes returns relationships, the facts you wrote in yourself and already have. The derived part gets computed to answer one question, then thrown away.

I tried all three and they stop in different places, but they stop. Permit.io is the only one attacking the problem at the root, with partial evaluation of the policy: instead of a list of ids it hands you a clause to drop into a WHERE. That's exactly the right thing. Only, on Postgres it's in early access, it works for attribute-based policies rather than relationship-based ones, and it wants the rules written in a separate language. The right answer exists. It just isn't available yet for the model I have.

What I did instead

I moved authorization into Postgres, as native functions. Two families: one for point checks, one that returns a set of ids.

SELECT r.*
FROM repositories r
WHERE r.id IN (SELECT authorized_repositories(:user_id))
  AND r.archived = false
ORDER BY r.pushed_at DESC
LIMIT 25;

A subquery like any other. It composes with the filters that were already there, with the sort and with the pagination. COUNT(*) tells the truth. Check and filter read the same data in the same transaction, so there's no window where permissions lag behind facts: there's nothing to synchronize, because there's no second place.

The switch cost little, for a reason that matters more than the solution itself. The application had never known about the external service. Use cases called a port with a deliberately generic signature (user, permission, context), and behind it sat an adapter. I wrote another one and touched no application logic.

What I lost

It isn't a clean solution and I don't want to sell it as one.

I lost the declarative model, which was readable: one file with the types, the relationships, and the permissions as expressions over them. Now the policy is code inside the database, versioned through migrations and verifiable only against a live database. And I lost those tests that ran in two seconds with nothing running.

I also don't know how far it holds. On the prototype it's instant, but a prototype doesn't carry a real customer's volumes, and I haven't measured anything under load yet.

Then there's the paradox that annoys me most. The prototype can afford native functions because its model is simple. The complex system, the one that would genuinely benefit from an external engine, is exactly the one with the deepest hierarchies, the longest lists and the largest volumes, which are the three things these tools don't help with. Whoever can afford them doesn't need them.

The doubt I'm left with

Maybe the question is wrong to begin with. The screen that lists everything a user can see doesn't exist in any product: GitHub shows you the repositories of an account or an organization, search works within a scope. If every query carries a mandatory scope, the candidate set stops being "everything that exists" and becomes a number I can bound. At that point filtering afterwards works again, because you filter the set and paginate at the end.

How have you solved this? I'm especially interested in anyone who went to production with a materialized index: how do you keep it up to date when something changes halfway down the chain?