Following a discussion on dev@, the materialized view feature is being
retroactively classified as experimental, and not recommended for new
production uses. The next patch releases of 3.0, 3.11, and 4.0 will include
CASSANDRA-13959, which will log warnings when materialized views are created,
and introduce a yaml setting that will allow operators to disable their
Concerns about MV’s suitability for production are not uncommon, and this just
formalizes the advice often given to people considering materialized views.
That is: materialized views have shortcomings that can make them unsuitable for
the general use case. If you’re not familiar with their shortcomings and
confident they won’t cause problems for your use case, you shouldn’t use them
The shortcomings I’m referring to are:
* There's no way to determine if a view is out of sync with the base table.
* If you do determine that a view is out of sync, the only way to fix it is to
drop and rebuild the view.
Even in the happy path, there isn’t an upper bound on how long it will take for
updates to be reflected in the view.
There is also concern that the materialized view design isn’t known to be
‘correct’. In other words, it’s a distributed system design that hasn’t been
extensively modeled and simulated, and there have been no formal proofs about
You should be aware that manually denormalizing your tables has these same
limitations in most cases, so you may not be losing any guarantees by using
materialized views in your use case. The reason we’re doing this is because
users expect correctness from features built into a database. It’s not
unreasonable for users to think that a database feature will more or less “just
work”, which is not necessarily the case for materialized views. If a feature
is considered experimental, users are more likely to spend the time
understanding it’s shortcomings before using it in their application.
The dev@ thread can be found here: