Which consistency level should a SpiceDB client request after a relationship write?

For an immediate read-after-write check where the permission result must never miss a write just performed by the same user, request fully_consistent on the permission call.

Confirmed behavior in SpiceDB 1.x authzed.api.v1

Assumption: SpiceDB 1.x server with a matching Go SDK. Exact minor version and API defaults should be verified against the current release notes before relying on the behavior described here.

• When the consistency field is omitted, the server defaults to minimize_latency. This is the default for Check and related calls in the stable API.
• minimize_latency may return cached dispatch results. It is not safe for read-after-write and is intended only for staleness-tolerant views.
• fully_consistent forces a read of latest committed data and cannot rely on cached dispatch results. It is the costliest option under write load.

Likely explanation vs confirmed facts

Confirmed: fully_consistent provides a strict read-after-write guarantee without requiring client state.

Likely: at_least_as_fresh with a ZedToken captured from the write response can provide equivalent freshness for the immediate follow-up check if the token is correctly propagated to that check. This may avoid the full cost of fully_consistent. The trade-off is operational: ZedTokens are opaque, the client cannot assess staleness, and loss or expiry of the token falls back to default behavior.

Minimal steps for this case

1. Write the relationship via the Go SDK and capture the ZedToken from the write response.
2. For the immediate re-render of permissions:
   • If you can reliably pass the captured ZedToken to the same request context that performs the Check, use at_least_as_fresh with that token.
   • If the token cannot be guaranteed to be available, or the check may be performed by a different service without token propagation, use fully_consistent.
3. Do not use minimize_latency or omit the consistency field for this read-after-write flow.

One diagnostic detail that changes the recommendation: can the Check that re-renders permissions access the ZedToken returned by the preceding write in the same logical request? If yes, at_least_as_fresh is viable; if no, fully_consistent is required.

Verification note: behavior is version-dependent. Verify defaults and token propagation semantics against your specific SpiceDB 1.x release notes.