I’m really pushing this for a SaaS app
# spicedb
t
I’m really pushing this for a SaaS app where most queries are “what can this user view/edit” or “what orgs is this user in”. It feels like anything less than SpiceDB-as-truth is just implementing the confused deputy problem. What has surprised you running/working with this in production? Things that were harder than expected or things you worried about that turned out not to matter?
j
The only issue we found was needing to join against metadata
so if you lookup what the user can view, then you need to lookup in the app DB the metadata (name, icon, etc) of those resources
t
That sounds manageable! Like, is it just a “WHERE id IN” query after the LookupResources call, or did you have to build caching/batching infrastructure to make it tolerable at scale?
j
yep and not really
most of our listing ops are bound or paginated
so the number of results to lookup is... 25 or 50
now, if you're doing ACL-aware search, then you can run into problems when needing to LR+a huge filter
but we built Materialize to handle that
y
i'll also chime in that we tried this at my last company for the management of IAMish groups, and what we found was that SpiceDB didn't work all that well as a general-purpose graph database, especially when we had to do manual JOIN-ish logic across sets of relationships. we ended up moving our source of truth out of spicedb and upstream to a normal postgres-backed service.
it'll depend heavily on the use case, the size of the data, and the engineering resources available to you for alternative approaches
5 Views