Here’s my perspective:
#1 Accord vs. LWT round trips
Based on the insights shared by the Accord experts, it appears that implementing MV using Accord can achieve a comparable number of round trips as the LWT solution proposed in CEP-48. Additionally, it seems that the number of WAN RTTs might be fewer than the LWT solution through Accord. This suggests that Accord is either equivalent or better in terms of performance for CEP-48.
Given this, it seems appropriate to set aside performance as a deciding factor when evaluating LWT versus Accord. I've also updated the CEP-48 page to reflect this clarification.
#2 Accord vs. LWT current state
Accord
Accord is poised to significantly reshape Apache Cassandra's future and stands out as one of the most impactful developments on the horizon. The community is genuinely excited about its potential.
That said, the recent mailing list update on Accord (CEP-15) highlights that substantial work remains to mature the protocol entirely. In addition, real-world testing is still needed to validate its readiness. Beyond that, users will require additional time to evaluate and adopt Cassandra 6.x in their environments.
LWT
On the other hand, LWT has been proven and has been hitting production at scale for many years.
#3 Dev work for CEP-48
The CEP-48 design has two major components.
Online path (CQL Mutations)
This section focuses on the LWT code path where any mutation to a base table (via CQL insert, update, or delete) reliably triggers the corresponding materialized view (MV) update. The development effort required for this part is relatively limited, accounting for approximately 30% of the total work.
If we need to implement this on Accord, this would be a similar effort as the LWT.
Offline path (MV Data Repair)
The MV repair tool in Cassandra is intended to address inconsistencies that may occur in materialized views due to various factors. This component is the most complex and demanding part of the development effort, representing roughly 70% of the overall work.
#4 Accord is mentioned as a Future Alternative in CEP-48
Accord has always been top of mind, and we genuinely appreciate the thought and effort that has gone into its design and implementation - We’re excited about the changes, and if you look at the CEP-48 proposal, Accord is listed as a 'Future Alternative' — not as a 'Rejected Alternative' — to make clear that we continue to see value in its approach and are not opposed to it.
Based on #1, #2, #3, and #4, here is my thinking:
Scenario#1: CEP-15 prod takes longer than CEP-48 merge
Since we're starting with LWT, there is no dependency on the progress of CEP-15. This means the community can benefit from CEP-48 independently of CEP-15's timeline. Additionally, it's possible to backport the changes from trunk to the current broadly adopted Cassandra release (4.1.x), enabling adoption before upgrading to 6.x.
Scenario#2: CEP-15 prod qualified before CEP-48 merge
As noted in #3, developing on top of Accord is a relatively small effort of the overall CEP-48 scope. Therefore, we can implement using Accord before merging CEP-48 into trunk, allowing us to forgo the LWT-based approach.
Given that the work required to support Accord is relatively limited and that it would eliminate a dependency on a feature that is still maturing, proceeding with LWT is the most reliable path forward. Please feel free to share your thoughts.
