Cassandra survey respondents prioritize scale and transactions

The strongest reasons respondents give for choosing Cassandra remain scalability and performance. Their most selected proposed feature is general-purpose ACID transactions. Those findings belong together. Users can value the database's existing distributed strengths while asking it to support application operations that are harder to express within its current transaction model.

The community published its 2024 user survey results on October 25. The first use-case question has 140 responses, but later questions have different totals. These results provide useful evidence about the participating community. They are not a census of every Cassandra deployment, and the publication does not establish a sampling method that would justify treating the counts as market shares.

I am attracted to Cassandra for active-active operation at scale, while preferring to use it only when that requirement exists. The survey helps explain the continuing attraction without removing that qualification. Respondents identify demanding database properties, and their requested features show where those properties still leave application work.

Scale is a concrete selection reason

The primary-reason chart records 109 selections for scalability, 101 for performance, and 86 for fault tolerance. Data distribution capabilities receive 69 selections, while stability receives 50. The page gives 139 responses for that question. The displayed category counts therefore should not be treated as a set of mutually exclusive percentages that add to one hundred.

This matters when interpreting the heading's phrase primary reason. The chart itself contains more selections than respondents. Its evidence supports comparing the displayed selections, but not claiming that exactly one category describes each participant's motivation. A reader needs to use the actual response structure rather than infer exclusivity from the wording.

The results also avoid reducing Cassandra's use to a single fashionable workload. The published free-text responses include ordinary application data and internal service discovery, as well as domain-specific uses. Those entries are examples supplied by participants. They demonstrate variety in the sample without establishing how common each use is across the wider population.

Transaction interest is a request

The proposed-features chart shows 79 selections for CEP-15 general-purpose ACID transactions. CEP-21 transactional cluster metadata receives 53. The question has 123 responses, again a different denominator from the opening use-case question. These are expressions of interest in proposed work, not observations of feature adoption.

That distinction is particularly important after the September 5 Cassandra 5.0 announcement. The release introduces SAI and vector search among other capabilities. A survey result about desired transactions does not imply that general-purpose ACID transactions shipped with that release.

The chart also distinguishes application transaction work from transactional cluster metadata. Their names share a term, but the proposals concern different responsibilities. Combining their counts into a single transactions percentage would hide that distinction and could count the same respondent twice.

Other displayed requests include live instance migration, diagnostic events in virtual tables, and a cost-based optimizer. Their presence suggests several directions participants want the project to explore. The chart supplies relative selection counts, but it does not allocate engineering effort or announce a delivery schedule.

I find the transaction result interesting because it expresses a desire to reduce application-level coordination work while retaining Cassandra's distributed storage role. That is my interpretation of the request, rather than a claim that the survey asked participants to explain that precise architectural motive.

Version counts need careful labels

The version question has 137 responses. Its chart records 78 selections for 4.1 and 44 for 4.0, alongside older and newer categories. It also includes broad labels such as 4 and 5, separately from 5.0. Those labels should remain distinct unless the underlying response data supplies a justified way to normalize them.

Likewise, multiple version selections need not describe one cluster running all those versions simultaneously. A respondent can have several clusters or environments. The published chart alone does not establish the deployment topology behind each answer, so adding the categories into a presumed installed-base distribution would introduce assumptions.

The older-version responses are operationally relevant because September's release announcement ends normal support for 3.0 and 3.11. That support decision is established independently by the announcement. The survey shows that older release labels still appear in this community sample, but it does not identify which specific organizations have completed an upgrade since responding.

Question-specific totals constrain comparisons

The page gives 138 responses for how people run Cassandra today, 105 for planned hosting changes, and 120 for upgrade timing among older-version users. Those totals describe different subsets of the participants. A planned change count cannot be compared directly with all current deployments as though every person answered both questions.

The same limitation applies to requested features and satisfaction questions. Non-response and the wording of each question affect what its chart represents. The useful reading keeps the counts attached to the question that produced them, without inventing a common denominator for the whole page.

For me, the survey is valuable as a set of specific community signals. Scale and performance remain prominent selection reasons, while proposed transactions receive substantial interest from the respondents answering that question. The published charts preserve those findings, and their separate response totals explain how far a quantitative comparison can reasonably go.