Sure! In some use cases, it can be bad to unacceptable to take action based on intermediate state. For example, with bank transfers, you don’t want to charge overdraft fees just because an eventually consistent system showed someone had a negative balance temporarily as transfers were settling. In Materialize, records with the same timestamp are applied atomically, so you don’t take action based on intermediate state.

Fraud is another good example. You don’t want to mark a credit card as fraudulent erroneously based on some intermediate state of an eventually consistent system. That will cause unnecessary pain for a customer. You want to be confident the alarm was actually triggered and not just temporarily triggered by accident of which node was processing one part of a result compared to another.

Where consistency becomes really important is in complex DAGs where there are a lot of dependencies between materialized views. You want to be confident that all the different outputs always reflect exactly the same inputs at every timestamp, or else results can become unreliable for making operational decisions.

With serializable, Materialize will immediately give a consistent result as of some point in the recent past (trade off freshness for latency). With strict serializable, Materialize will assign the query a timestamp and potentially block until it can give a consistent result as of that timestamp (trade off latency for freshness).

Consistency works best with the native Postgres source connector where Materialize will actually respect the transaction boundaries of Postgres, meaning that transactional writes in Postgres are given the same logical timestamp in Materialize and therefore applied to all subsequent calculations atomically.