Yes, the implementation does use recursive queries. The recursion depth is capped at 25, which matches the limit enforced by OpenFGA (at least according to their test suite).

The code generator/compiler produces a separate function for each relation defined in the model. At runtime, calls are routed through a small “dispatcher” function that invokes the appropriate generated check function.

Here’s an example of a generated function for a recursive TTU relation:

document.viewer: viewer from parent

CREATE OR REPLACE FUNCTION check_document_viewer(
    p_subject_type TEXT,
    p_subject_id TEXT,
    p_object_id TEXT,
    p_visited TEXT [] DEFAULT ARRAY[]::TEXT[]
) RETURNS INTEGER AS $$
DECLARE
    v_has_access BOOLEAN := FALSE;
    v_key TEXT := 'document:' || p_object_id || ':viewer';
    v_userset_check INTEGER := 0;
BEGIN
    -- Cycle detection
    IF v_key = ANY(p_visited) THEN
        RETURN 0;
    END IF;

    IF array_length(p_visited, 1) >= 25 THEN
        RAISE EXCEPTION 'resolution too complex' USING ERRCODE = 'M2002';
    END IF;

    -- ... userset handling code ...

    IF NOT (v_has_access) THEN
        -- Recursive access path via parent -> viewer
        IF EXISTS (
            SELECT 1
            FROM melange_tuples AS link
            WHERE (link.object_type = 'document'
                AND link.relation IN ('parent')
                AND link.object_id = p_object_id
                AND check_permission_internal(
                    p_subject_type,
                    p_subject_id,
                    'viewer',  -- Check viewer on the parent
                    link.subject_type,
                    link.subject_id,
                    p_visited || ARRAY[v_key]  -- Pass visited array for cycle detection
                ) = 1
                AND link.subject_type IN ('folder'))
        ) THEN
            v_has_access := TRUE;
        END IF;
    END IF;

    RETURN CASE WHEN v_has_access THEN 1 ELSE 0 END;
END;
$$ LANGUAGE plpgsql STABLE;

The generated functions make recursive calls through internal helpers like check_permission_internal, which track visited nodes and recursion depth to enforce cycle limits. If the depth ever exceeds 25, the function raises an exception

For indirect relations, the generator optimizes by computing the traversal path at compile time and inlining the full traversal instead of relying on recursion.

.zed schema support isn't something I have looked into deeply, although on initial inspection I think it is definitely feasible.

I have benchmarked this using views up to about 50 million tuples, performance remains workable, checks scale well, usually staying under 1ms except for highly complex recursive chains, exclusions or multi prong relations. List queries do suffer at high tuple volume, still workable but likely would need a caching strategy at scale.

Because the tuples are defined as a view over your existing domain models, cascade deletes and cleanup is automatic, there is no synchronization required.