so matching the already present concreet limit ?

(I mean the parameter)

yes, but with an additional issue: wildcards impact the intermediate tree

so we still need to carry them somewhere

and that causes problems

Hi everyone! How's it going? I have a question about read consistency: If I write a relation to spicedb and try to read it immediately after, is there a chance I might get nothing? I'm using the default consistency option (which I guess is the minimize_latency) I have this scenario in which I write relatioships and, right after, another service tries to check a permission. However, it sometimes gets a falsy response from the check (even though all writes happened successfully)

Yeah, I don't want to disturb the upper thread, so I'll start a new one, but the question is quite related. How should we work with

zedtoken

in a microservice architecture when permissions are granted/revoked by admins? For granting permissions, there is no big problem. You can grant the permission in one service and eventually send the

zedtoken

to another service or store it in a DB. It is acceptable if the user gets access a couple of seconds later. But what happens when we remove/revoke a permission? Revoking a permission should ideally take effect immediately. Imagine an admin revokes a user's permission in one service/pod. We then need to propagate the corresponding

zedtoken

to the service handling the user's queries as quickly as possible. If everything is handled within one microservice, we have the problem of storing the

zedtoken

in two databases (SpiceDB and our DB). Potentially, we could lose the latest

zedtoken

if our DB transactions fail. If the permission management and user queries are handled by different microservices, we have the same persistence problem, plus eventual consistency. We need to somehow transfer the

zedtoken

to another microservice, which could take some time depending on the implementation (Kafka, etc.). So, in this case, understanding whether a relation was deleted by an admin is not immediately possible unless we use

fully_consistent

for such queries. Am I missing something here? Is there a recommended pattern for handling

zedtoken

propagation in this kind of architecture, especially when permission revocation needs to take effect immediately? Thanks in advance.

Hi folks 👋 I'm evaluating SpiceDB for my company and had a question around backups. We'd be using AWS RDS Postgres as the datastore. Based on what I'm reading (e.g. https://authzed.com/docs/spicedb/ops/data/migrations), it seems like

pg_dump/restore

is not recommended and instead we should be using

zed backup

for backups. For the same reasons, should RDS automated backups be avoided, or are they fine as those are physical snapshots of storage rather than logical backups produced by

pg_dump

?

Hi, We've been using SpiceDB for almost two years now, and I would say we have a fairly large schema. We've run into an issue twice where the namespace cache hit ratio suddenly starts dropping, and then two out of our four SpiceDB pods continuously increase their heap memory usage until they eventually stop responding to authorization requests. After the first occurrence, we increased the namespace cache size from 256 MiB to 512 MiB, but the issue happened again. What's interesting is that we haven't been able to identify any clear trigger. One time it started on a Sunday, and the other time it started during a regular weekday morning. Our relevant configuration is: SPICEDB_DATASTORE_REVISION_QUANTIZATION_MAX_STALENESS_PERCENT: "1" SPICEDB_DATASTORE_REVISION_QUANTIZATION_INTERVAL: "5s" SPICEDB_ENABLE_EXPERIMENTAL_WATCHABLE_SCHEMA_CACHE: "true" SPICEDB_DATASTORE_SCHEMA_WATCH_HEARTBEAT: "60s" SPICEDB_NS_CACHE_MAX_COST: "512MiB" SPICEDB_DISPATCH_CACHE_MAX_COST: "256MiB" SPICEDB_DISPATCH_CLUSTER_CACHE_MAX_COST: "512MiB" We are using PostgreSQL as the datastore. Another important detail: our schema is essentially static. We only deploy schema changes together with a new application version and after restarts. The schema itself is roughly 4,000 lines long. I've attached a screenshot showing the namespace cache hit ratio dropping. Under normal conditions it stays close to 100%. After restarting the affected pods, it returned to normal. It also looks like cache entries may have started getting evicted overnight, although unfortunately the screenshot doesn't include the very beginning of the issue. Has anyone seen similar behavior or has ideas about what could cause the namespace cache hit ratio to suddenly drop and memory usage to keep growing on only a subset of pods? https://cdn.discordapp.com/attachments/844600078948630559/1536684965142732900/image.png?ex=6a7c4ce5&is=6a7afb65&hm=3d5c660ca04c593003f547389955c83ae7ab0e72e53ec2c279d38f04c4029588&

Hey! We’d appreciate some guidance on whether we’re using SpiceDB correctly for resource ownership and list queries. Our resources are stored in PostgreSQL, but their workspace relationship currently exists only in SpiceDB:

definition resource {
    relation workspace: workspace

    permission view = workspace->can_view_resources
    permission edit = workspace->can_edit_resources
    permission manage = workspace->can_manage_resources
}

To list resources, we currently: - Use fully consistent ReadRelationships to retrieve every resource ID associated with the workspace. - Pass those IDs to PostgreSQL using WHERE id IN (...). - Apply filtering, sorting, counting, and pagination in PostgreSQL. A real request for 50 rows generated a query containing hundreds of IDs and took approximately six seconds:

SELECT *
FROM resources
WHERE id IN (<hundreds of IDs>)
  AND deleted_at IS NULL
ORDER BY created_at DESC
LIMIT 50;

We haven’t confirmed that the large IN clause is the only cause, but the query size grows with the workspace’s total number of resources rather than the requested page size. We’re considering making PostgreSQL authoritative for ownership and discoverability:

resources.owner_workspace_id
resource_workspace_access(resource_id, workspace_id)

SpiceDB would remain responsible for deciding whether a workspace or user can view, edit, or manage a resource. My questions are: - Is our current ReadRelationships → PostgreSQL IN (...) approach an intended SpiceDB pattern, or are we using SpiceDB incorrectly? - Is PostgreSQL ownership/discovery combined with SpiceDB action authorization a better architectural boundary? - For resources shared across workspaces, where should that relationship live, and how would you keep PostgreSQL and SpiceDB consistent? Any feedback or examples from similar systems would be very helpful.

Bringing this Q here at Joseph Schorr's suggestion. We have an application where we would like some roles to be discretionary. We mostly want users operating in a "base" role, but if they are also (in our specific case) a board member, we want them to be able to activate the additional authority and access rights that go with being a board member on a discretionary basis. It's not a serious security distinction, but it's a useful way to avoid fat-fingering things. There are a bunch of similarly discretionary roles, but if we can model one we can probably model the rest. First question is: what's a good way to model this? Second question: how does that model change if we want it to be session specific? If I enable my "board" role on my phone, it shouldn't get enabled on the desktop I left logged in at home!

Hi, has anything changed about https://github.com/authzed/spicedb/issues/2769 per chance?

not at this time

I read the article https://authzed.com/blog/the-dual-write-problem-in-spicedb-a-deep-dive-from-google-and-canva-experience and saw that you mention 4 recommended methods for solving a race condition. When spicedb only contains the permissions and the central db does not contain the permissions, the sync methods are irrelevant. Is referring to spice as a db that is responsible for saving the information without it also being in the central db incorrect? What is the alternative to handling a race condition if I am not interested in the fifo in outbox method?

👋 Just a question around when you think this fix could be released? https://github.com/authzed/spicedb/commit/9b5cdc1e849249ecd31cfeca82149767dbb8760f#diff-081ec660ff70201670d1b29e8f85ee11de9feef9a2119c565a99f5006a7444d6 We've increased the namespace cache quite a lot using version 1.54.0 but the performance is still deteriorating over time which forces us to restart pods from time to time in order to reduce latency

Hi. We have an RDS-backed spicedb instance and we'd like to migrate to an identical RDS-backed setup in a new AWS account. I saw this page https://authzed.com/docs/spicedb/ops/data/migrations warning against using pg_dump and pg_restore; is the AWS database migration service also unsupported (meaning we'd have to use the CLI tool)? I understand there are some tradeoffs with downtime where we'd probably be better off using the zed CLI + watch API, but DMS might be simpler for a few different reasons and I wanted to check if that was an option. Thanks!

Hi folks. I'm trying to develop a schema and I have some questions regarding when to use

->

or

#

. What is the best pattern here or gotchas? So my schema is

definition user{}

definition platform {
    relation admin: user
    relation member: user

    permission admins = admin
    permission members = admin + member
}

definition group {
    relation member: user
    relation manager: user
    relation platform: platform

    permission membership = member + manager + platform->members
    permission view = member + manager + platform->members
    permission edit = platform->admins
    permission manage = manager + platform->admins
    permission delete = platform->admins
}

definition service {
    relation public: user:*
    relation user: user | group#membership
    permission access = public + user
}

definition assessment {
    relation owner: user
    relation editor: user | group#membership
    relation viewer: user | group#membership

    permission read = owner + viewer + editor
    permission edit = owner + editor
    permission share = owner
    permission delete = owner
}

in group definition I'm pointng to platform->members so my question: Where should

platform->members

point to a relation or a permission? I'm not sure my question is clear..sorry

Hi folks. i had a question on best practices on writing test cases for my spicedb setup. right now i'm setting up a real spicedb while running my battery and it is quite intensive and time consuming. what's the recommended way to test my spicedb integration to my application?

are you using

serve-testing

?

Yes

how we use it right now: - every test gets its own token, so its own in-memory datastore - that's thousands of datastores per test run, and they never get freed. the container ends up at 17-22 GB - a lot of our tests start from a pre-seeded world, so each one loads that world's relationships into its fresh datastore first that setup is where all the time goes. i profiled one test: 74s of setup, and 68.7s of it was just writing the org's starting relationships (through our own code, to be fair) is there a better pattern for this? like reusing a seeded datastore across tests instead of reloading it every time?

Been struggling with my test battery just running for 20-30 mins for every small change.

I'd recommend starting by not writing as many rels per test, if you can do so

and using a shared loader

we've considered having tokens expire, or providing an API to do so

but often making each test's data smaller is a good starting point

thanks, that helps! one more: for app logic tests (not the schema itself), do people usually hit serve-testing for everything, or use a fake/mock and keep a small set of tests on the real thing?

depends on the person; I typically use a small fake for unit tests, but serve-testing for anything bigger

longer term, our new (right now experimental) client libraries will support an in-memory running of SpiceDB to be used for unit tests, if preferred: https://github.com/authzed/spicedb-clients-prototype

thank you very much!