The road to ACID transactions in Cassandra 6
eatonphil
68 points
18 comments
August 21, 2026
Related Discussions
Found 5 related stories in 53.1ms across 4,128 title embeddings via pgvector HNSW
- Every Company Needs a Cassandra mattzcarey · 11 pts · August 10, 2026 · 45% similar
- Snapshots, copy-on-write, and the economics of agent sandboxes nikhilunni · 15 pts · July 23, 2026 · 38% similar
- Rethinking Database Programming honungsburk · 235 pts · August 18, 2026 · 36% similar
- 'We used acid to sabotage Microsoft hyperscale data centre construction' lowbar · 68 pts · July 16, 2026 · 36% similar
- Aurora DSQL: Scalable, Multi-Region OLTP shenli3514 · 17 pts · July 17, 2026 · 36% similar
Discussion Highlights (3 comments)
javier2
Thanks for this, really looking forward to the release of Accord
cyberpunk
I'm sure for some workloads, cassandra is 'ideal' or at least was 10 years ago. What I can say though (as someone running thousands of cpus worth of cassandra at the moment); is that I deeply dislike this database. It's an operational nightmare, and I will not miss it even the slightest bit if it goes away forever. On the other hand, I'm sure glad to see a bit of life in cassandra dev, it seems to have been dormant for a while; but would I pick it for new applications in 2026? No. I'd strongly recommend against using it unless you have the money to pay for a dedicated team to maintain it, and even then just.. No.
farazbabar
I see a few comments talking about the pain cassandra inflicts on ops, and that's fine, I agree with almost all of them. What the comments assume readers to know and understand is the absolute horror of foot guns, backup nightmares, data loss scenarios with seemingly safe choices around quorum and of course the performance purgatory lined with tombstones. Honestly, your workload is not big enough for postgres, trust me. It is like trying to do word count on a 5 TB file with flink, can you? should you though?