Skip to content

docs: Hydration details and concepts page - #38168

Open
kay-kim wants to merge 1 commit into
MaterializeInc:mainfrom
kay-kim:docs-hydration-updates
Open

docs: Hydration details and concepts page#38168
kay-kim wants to merge 1 commit into
MaterializeInc:mainfrom
kay-kim:docs-hydration-updates

Conversation

@kay-kim

@kay-kim kay-kim commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

https://preview.materialize.com/materialize/38168/concepts/hydration/

Part 1 of Hydration content:

  • Added a yaml file to capture the details (including when objects hydrates and the memory usage)
  • Added the concept page for hydration which mostly uses the details from the yaml file.

Once approved and merged, Part 2 will include the approved details in appropriate places.

@kay-kim
kay-kim requested a review from a team as a code owner August 11, 2026 21:09
materialized view (public preview) and replacing the existing view in
place](/transform-data/updating-materialized-views/replace-materialized-view/)
may be simpler, but briefly reduces freshness.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did not include compute_hydration_concurrency as a strategy

Hydration primarily impacts memory usage, and its speed scales with cluster
size. Some hydration-related strategies you may want to consider:

- Add an [`AUTO SCALING STRATEGY (ON HYDRATION)`](/sql/alter-cluster/) to your

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably will move it to the hydration-details.yml later on.

then removes it once a steady-size replica catches up. You pay for the burst
replica while it is provisioned, but not at steady state.

- Split materialized views and indexes across multiple clusters. Each cluster

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this! I'd recommend checking out what @tylerhartwig did to shard MVs well. There's a number of strategies you can employ and I think sharing more details would help

require a significant amount of CPU and memory.

- During hydration (both initial and subsequent rehydrations), materialized
- During hydration (both initial hydration and subsequent rehydrations), materialized

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure where to put this, but rehydration technically uses more memory! I'll let @antiguru confirm, but my understanding is:

  1. If you create a cluster for a first time with 10 MVs, you'll use X memory
  2. If you restart that cluster and have to rehydrate the 10 MVs, you'll need 2X memory

It might be worth splitting up those concepts and specifying the memory requirements for both

@kay-kim kay-kim Aug 12, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, heh .. I think I clobbered that line where we stated "materialized views require memory proportional to both the input and output." (i.e., your 2X 😄 ) But, will also wait for confirmation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants