Apache Cassandra
Materialized Views
Learn how materialized views automate denormalization for alternate query patterns, and understand their operational risks.
A materialized view (MV) in Cassandra automatically maintains a denormalized copy of a base table's data, re-keyed with a different primary key to support an alternate query pattern — without requiring the application to manually write to multiple tables. When the base table changes, Cassandra transparently propagates the change to the view.
A materialized view is like having an assistant who automatically re-files a copy of every document you create into a second cabinet organized differently — convenient, but if the assistant ever misses an update during a busy day, the two cabinets quietly stop matching.
Key Concepts
1
Materialized views were introduced to reduce the burden of manual denormalization described in query-first modeling. Instead of writing application code to keep an orders_by_customer and orders_by_product table in sync, a developer could define a view once and let Cassandra handle propagation.
orders_by_customerorders_by_product
2
However, materialized views have a troubled history in production due to subtle consistency bugs, especially around view updates during node failures, repairs, and streaming operations — base table and view can drift out of sync silently. As a result, materialized views were marked experimental in later Cassandra versions, and many teams and even the Cassandra project itself recommend against using them in production, favoring manual denormalization or application-side dual writes instead.
experimental
3
Understanding materialized views — including why they fell out of favor — is a common interview topic because it demonstrates awareness of real operational trade-offs rather than just textbook features.