Hydration

Hydration is the process Materialize uses to turn your SpiceDB schema and relationship data into the precomputed permission sets that both Materialize features depend on: Accelerated Queries reads hydrated data directly to answer checks and lookups, and Event Streams exposes that same hydrated data through LookupPermissionSets and WatchPermissionSets.

Only what’s reachable

Hydration doesn’t compute every permission your schema could produce, only the permissions you’ve configured Materialize to watch, plus everything those permissions structurally depend on through unions, intersections, exclusions, and arrows. This reachability is a pure function of your schema and your watched permissions, so Materialize computes it once per hydration run and reuses it throughout.

This is also why the cost of hydration tracks the size of the reachable graph, not the size of your whole schema: watching a permission with a much wider reach, or adding a new watched permission, can noticeably change how much work hydration has to do.

Offline hydration vs. online hydration

• Offline hydration reads a full snapshot of your relationship data and computes every reachable permission set from scratch. This is what backs the initial backfill.
• Online hydration applies as new relationship and schema changes arrive after that initial pass, updating only the permission sets a given change actually affects, in the order the changes occurred.

When rehydration is required

A breaking schema change invalidates previously hydrated permission sets, since the reachability computed from the old schema no longer holds. Materialize signals this so you can re-run the backfill at the new revision. See The Permission Set Lifecycle for the full rebuild flow.