SpiceDB watch stream latency under high write throughput: what limits apply?

We are designing a service that relies on SpiceDB's watch API to propagate authorization changes to downstream caches in near real time. The documented behavior is that the watch stream delivers changes with the consistency guarantees of the backing datastore, but it is less clear what happens to delivery latency when write throughput spikes.

Our concern is subscription queue buildup: if many clients hold open watch streams while the datastore processes a burst of relationship writes, do events queue per-subscription, and is there a documented bound or backpressure mechanism before events are dropped or the stream is terminated? We have not yet run a benchmark, and we want to understand the expected limits before measuring.

Assuming a recent SpiceDB version on PostgreSQL or CockroachDB as the datastore:

• Is there a documented per-stream buffer or timeout that governs how far behind a watch consumer can lag before the stream fails?
• Does watch latency scale with total write throughput, or only with writes matching the subscribed object types?
• Are there recommended metrics to observe queue depth before deciding whether to shard watch consumers?