Hey, I think I see what's happening here — the caveat devices_under_limit is being evaluated against every subscriber of that subscription plan at check time. So when a plan has 110k subscribers, SpiceDB is essentially spawning goroutines for each one to evaluate the caveat, which explains both the goroutine explosion and the memory spike. Could be wrong but that fan-out might be it is what I felt. One approach that might help — instead of checking device limits at query time via caveat context, you could manage that constraint at write time on the application side, and only write a relationship to SpiceDB when the session is actually valid. That way the check stays O(1) regardless of how many subscribers a plan has. Anyway just a thought, if it sounds viable happy to go deeper on it!