HN Debrief

The road to ACID transactions in Cassandra 6

  • Databases
  • Infrastructure
  • Open Source

The post walks through Cassandra 6’s path to transactional guarantees, centered on Accord, a protocol meant to bring ACID transactions to a system built around partitioned, eventually consistent data. That is a meaningful shift for Cassandra because the usual trade has been write-heavy scale and geographic distribution in exchange for a lot of application-side compromise around consistency, data modeling, and failure handling.

If you are evaluating databases for a new system, do not let “ACID transactions in Cassandra” pull you past the first question: do you actually need Cassandra’s scale and failure model. For most teams, the practical move is still to start with Postgres or a managed service and treat Cassandra-class systems as a last resort reserved for workloads that have already outgrown simpler options.

Discussion mood

Mostly negative on Cassandra as a product, even from people actively running it. The mood was weary rather than hostile: respect for its ability to handle extreme write-heavy workloads, but strong frustration with operational fragility, painful recovery and backup stories, and a sense that new features like transactions do not fix the reasons most teams should avoid adopting it.

Key insights

  1. 01

    Operational failures dominate the cost

    Running Cassandra at scale was described as a string of sharp edges that do not show up in benchmark-driven architecture decisions. The hard parts were quorum choices that still lose data or availability in surprising ways, repair jobs that become permanent maintenance, backups and restores that are easy to get wrong, commit log corruption during bad exits, and tombstones that quietly turn normal queries into performance disasters. That reframes Accord. Better transaction semantics help developers, but they do not touch the failure modes operators spend their time fighting.

    If you are considering Cassandra, do a day-two review before a feature review. Ask how your team will handle repair, restore, node replacement, and split-brain scenarios before you get excited about new consistency features.

      Attribution:
    • farazbabar #1
    • cyberpunk #1
  2. 02

    Sharded MongoDB is now a serious replacement

    For new write-heavy systems, one operator said they would pick a sharded MongoDB cluster over Cassandra, ScyllaDB, or CockroachDB. The point was not that MongoDB is magically simpler, but that modern MongoDB after WiredTiger has become operationally boring enough to trust again, which is a huge advantage over databases that demand constant care just to stay healthy.

    If your use case is pushing you toward Cassandra-class systems, add modern MongoDB to the shortlist instead of relying on old assumptions. Evaluate operational maturity and recovery behavior as heavily as raw write throughput.

      Attribution:
    • cyberpunk #1
  3. 03

    ScyllaDB remains the nearest fit with caveats

    ScyllaDB was treated as the most natural home for teams that like Cassandra’s data model and scaling shape, and several comments implied it is the easiest conceptual migration path. The catch is licensing and product direction. Since the open source version was discontinued, teams that care about staying on a current open base are left with an awkward trade between familiarity and long-term control.

    If you are already in the Cassandra family, ScyllaDB may still be the most practical comparison point. But factor licensing risk and upgrade path into the architecture decision, not as procurement cleanup later.

      Attribution:
    • heipei #1
    • kapperchino #1
    • javier2 #1

Against the grain

  1. 01

    Postgres advice ignores extreme scale cases

    Pushing everyone toward Postgres glosses over workloads where a single large machine is nowhere near enough and multi-master options are still immature or unproven for cautious operators. From that angle, saying “just use Postgres” is less a recommendation than a signal that the speaker has never had to replace a 6 to 12 node Cassandra cluster serving sustained high write volume.

    Treat blanket “use Postgres” advice as a default, not a law. Once your workload truly needs horizontal write scaling across many nodes, revisit distributed designs early instead of forcing Postgres past its comfort zone.

      Attribution:
    • cyberpunk #1

In plain english

Accord ↩
A transaction protocol being added to Cassandra to coordinate consistent multi-key operations across distributed nodes.
ACID ↩
Atomicity, Consistency, Isolation, Durability, the standard properties that make database transactions reliable.
Cassandra ↩
Apache Cassandra, a distributed NoSQL database designed for high availability and large-scale writes across many servers.
CockroachDB ↩
A distributed SQL database that aims to provide transactional consistency while scaling across multiple machines.
commit log ↩
An append-only record of recent writes used by a database to recover data after crashes.
eventually consistent ↩
A data consistency model where replicas may temporarily disagree, but are expected to converge to the same value over time.
MongoDB ↩
A document-oriented database that stores flexible JSON-like records and can be scaled across multiple servers.
Postgres ↩
PostgreSQL, a widely used open source relational database.
quorum ↩
A rule that requires responses from a minimum number of replicas before a read or write is considered successful.
ScyllaDB ↩
A distributed database compatible with Cassandra’s data model and protocol, designed for high performance with a different implementation.
tombstones ↩
Special markers used by Cassandra to represent deleted data, which can build up and make reads slower or more expensive.
WiredTiger ↩
The storage engine used by modern MongoDB versions that improved durability, compression, and operational stability.