Agent Memory at Monster Scale with Mem0 and ScyllaDB Cloud

7 July 2026, 1:08 pm by ScyllaDB

Combine Mem0’s memory management with ScyllaDB’s persistence features to deploy large-scale AI agents Scaling AI agents to handle persistent memory for a large number of users (e.g. 500k+ DAU) introduces engineering bottlenecks. These complications generally compound across two areas: how context is filtered for the model and how that data is stored globally. Mem0 addresses context efficiency… Source

What’s Coming in Cassandra? Key Apache Cassandra CEPs to Watch

7 July 2026, 12:52 pm by Apache Cassandra - Instaclustr

Introduction

Apache Cassandra’s contributors continue to push the database forward, and the Cassandra Enhancement Proposal (CEP) process is where that work takes shape. A CEP is a proposal to design, discuss, and build a meaningful change, with the author signaling real intent to implement it and to gather community consensus along the way.

We have previously covered CEPs here, some of which are anticipated to be present in Apache Cassandra 6 (currently in alpha). In this article we look at five CEPs that together touch many layers of Cassandra: replica consistency (CEP-45: Mutation Tracking), data placement and balancing across a cluster (CEP-60: Flexible Placements), cluster administration (CEP-38: CQL Management API and CEP-62: Cassandra Configuration Management via Sidecar), and efficient use of the underlying hardware (CEP-49: Hardware-accelerated compression).

All of these CEPs have been accepted, but as with all open source development, inclusion in a future release depends on successful implementation, community consensus, testing, and approval by project committers.

CEPs Discussed CEP-38: Cassandra CQL Management API

What it does: Adds a native Cassandra CQL interface so operators can run cluster administration tasks directly through CQL instead of depending on JMX-backed tooling.

Most Cassandra admin tasks, from taking a snapshot to running a compaction, run through JMX MBeans, and the tools operators depend on, like nodetool and the Cassandra Sidecar, all speak to them over JMX. The ecosystem has worked around this over the years by wrapping JMX in REST APIs or bypassing it with Java agents, but these layers sit on top of an internal API that was never designed as a stable contract. There are further drawbacks to that coupling, from JMX’s security exposure and operational complexity to the cost of maintaining nodetool and the lack of structured command metadata from the server.

CEP-38 intends to make CQL the management interface to run commands directly, removing the dependence on JMX and external tooling in addition to aligning administration with the same interface developers already use. Defining each command once in a single registry with structured metadata gives the agents and plugins that expose a REST API something solid to build on.

Here’s an example using the CQL syntax, per the CEP’s documentation:

EXECUTE COMMAND forcecompact WITH keyspace=distributed_test_keyspace AND table=tbl AND keys=["k4", "k2", "k7"];

Just as important, it moves command execution toward an asynchronous, observable model: instead of executing and blocking, a command can be submitted, return an identifier to track it, and have its result observed afterward.

This flow is intended to lay the groundwork for automation and higher-level workflows in the future. Underpinning both the CQL interface and this execution model is a single command registry that defines each command once and exposes it consistently across interfaces. This would prevent drift between JMX, the CLI, and any REST layer.

With behavior centralized, nodetool and cqlsh stop being separate implementations and become thin entry points over the same operations. A dedicated management surface that can be reached on its own admin port gives the control plane a clear boundary that higher-level orchestration can build on.

This CEP benefits operators administering clusters and developers building and working with management tooling. Crucially, the CEP doesn’t aim to remove or deprecate the existing MBeans or CLI tools. JMX will keep working, but it nudges the project toward a state where deprecating JMX could eventually become feasible.

CEP-45: Cassandra mutation tracking for replica consistency

What it does: Tracks individual writes by ID rather than comparing whole partitions across replicas.

Cassandra has two ways of catching writes that didn’t reach every replica, repair and read repair, but both work by pulling stored data from multiple nodes and comparing it, which is expensive.

Repair ships whole partitions between nodes when it finds a discrepancy, driving up streaming and compaction work and making very large partitions impractical. On the other hand, read repair only fixes the slice of a partition a query touched. This can leave a write half-applied and undermine Cassandra’s partition-level write atomicity. It also can’t provide read monotonicity—an important property of quorum reads and writes—for witness replicas without read-repairing nearly every read, which has limited their usefulness.

CEP-45 takes a different approach. Rather than comparing data on disk, each write is tracked individually: the coordinator stamps every write with a unique ID that travels to the replicas, and each replica records which IDs it has applied. At read time, one replica returns the data plus a summary of its applied IDs while the others return only that summary; matching summaries mean the data is accurate, and any gaps are filled by sending the specific missing writes. A background process continually reconciles these IDs across replicas and establishes a lower bound (kind of like a watermark) that signals older log entries can be cleaned up.

The feature is enabled per keyspace or table through a new replication-type setting and reuses Accord’s addressable commit log, which adds an index over Cassandra’s commit log so individual entries can be retrieved by ID.

Repair and read repair have long been operational burdens for Cassandra operators. Reconciling at the level of individual writes instead of whole partitions should cut streaming and compaction cost and ease partition-size limits.

CEP-49: Hardware-accelerated compression

What it does: Offloads compression work to hardware accelerators where available, freeing CPU for other tasks.

Cassandra ships with four compressors (LZ4, Zstd, Deflate, and Snappy) and compressing and decompressing data eats a meaningful share of CPU during flush and compaction. Compression can also apply to the commitlog and to data moving across the network.

Some newer processors carry built-in accelerators for this work, such as Intel’s QuickAssist Technology (QAT) on Intel Xeon chips, which can accelerate LZ4, Zstd, and Deflate. The proposal intends to hand compression off to that hardware where it exists, freeing CPU for other tasks and speeding up compression itself.

CEP-49 adds a framework that uses the accelerator when present and reverts to the software compressor otherwise, with room to plug in other accelerators later. Backends ship as separate plugins that Cassandra discovers at startup and it falls back to the standard compressor if a plugin fails.

The main beneficiaries are operators running compression-heavy workloads on capable hardware, though the framework is also designed to support other hardware-based compressors in the future.

Note: The hardware must already be configured correctly, and anything not functioning falls back to default software-based compression.

CEP-60: Flexible Placements for cluster scaling and balancing

What it does: Decouples data placement from token ring position, enabling steadier cluster utilization and more granular scaling.

In the current model, a node’s token positions on the ring determine which data it owns, which causes several problems. Growing a cluster cheaply tends to require doubling it; while a node joins, its range is temporarily served by an extra replica, adding load. On vnodes, tokens can’t be moved, so fixing an unbalanced ring falls on the operator and there’s no way to plan a large change as one operation or break a long one into smaller retriable steps.

CEP-60 decouples placement from token position, making the “tablet”—a range for a specific keyspace/table pair—the unit of ownership, with replicas assigned directly. Built on CEP-21’s transactional cluster metadata, it lets bootstrap and streaming run in smaller resumable steps. It also decides where data lives using per-range load and capacity metrics, moving away from ring percentage.

A central benefit is better node density. Because the cluster stays close to balanced at any size, operators can run nodes at higher, steadier utilization. By contrast, token-based growth produces a sawtooth pattern, forcing operators to provision for the peak and pay for idle capacity. Keeping nodes near a target utilization, and growing a few nodes at a time, translates into fewer wasted machines and potentially lower cost.

CEP-62: Cassandra configuration management via Sidecar

What it does: Adds a Sidecar REST API for programmatically reading and modifying cassandra.yaml and JVM options files.

Many Cassandra settings, like memtable configuration, SSTable options, and storage_compatibility_mode, live in cassandra.yaml and can’t be changed while a node is running. Additionally, startup tuning such as heap size and garbage collection lives in JVM options files. Runtime settings can be adjusted through JMX, but for these on-disk files Cassandra offers no programmatic interface, leaving operators to edit them by hand or with custom scripts. An earlier addition let the Cassandra Sidecar start and stop instances, but it still couldn’t touch the configuration those instances read at boot.

CEP-62 fills that gap with a Sidecar REST API for reading and changing cassandra.yaml and JVM options. It layers a sparse “overlay” of explicit changes on top of a base template and merges the two into the configuration a node actually uses; a pluggable provider can keep overlays locally or in a central system like etcd or Consul. A version-aware check rejects settings a given Cassandra version wouldn’t recognize, reducing the risk that a typo or unsupported setting leaves a node unable to start. Changes apply on the next restart, and everything lives in Sidecar with Cassandra left untouched.

This helps operators managing configuration across many nodes, especially those wiring Cassandra into centralized configuration tooling. It’s disabled by default and purely additive, so existing deployments and anyone not running Sidecar are unaffected, and it lays groundwork for later work on driving Cassandra upgrades through Sidecar.

Conclusion

Altogether, these proposals show a project investing in the things that matter most to the people who run it: reliability, operability, and efficiency. Mutation tracking and flexible placements aim to make data consistency and cluster scaling less costly and less manual. The CQL management API and Sidecar-based configuration management give operators stabler, more programmable ways to administer their clusters. Hardware-accelerated compression squeezes more out of modern hardware.

Each feature aims to lower the operational challenges of running Cassandra at scale both for self-hosted clusters and managed Cassandra providers such as NetApp Instaclustr, and several CEPs lay groundwork that future enhancements will build on.

Following the CEP process is one of the best ways to see where Cassandra is headed. We’ll keep tracking these proposals as they move through implementation, and we look forward to seeing them land in users’ hands in future releases.

Ready to run Cassandra without the operational complexity? Try NetApp Instaclustr for Apache Cassandra free for 30 days today! Our managed platform handles the infrastructure, configuration, and operational heavy lifting so your team can focus on building applications.

The post What’s Coming in Cassandra? Key Apache Cassandra CEPs to Watch appeared first on Instaclustr.

ScyllaDB vs Aerospike, Wide-Column vs. Key/Value

6 July 2026, 1:13 pm by ScyllaDB

Wide-column flexibility doesn’t have to come at the expense of performance — see where the two models differ, where each one wins, and why you no longer have to choose Aerospike published a paid benchmark to show it’s faster. Color me surprised…it defined the winner as itself. Aerospike benchmarked the one workload its architecture is built for. This article shares the fuller picture: what a… Source

Cutting P99 Latency 1000X During Connection Storms by Hardening ScyllaDB Admission Control

1 July 2026, 1:35 pm by ScyllaDB

ScyllaDB successfully mitigated performance-degrading connection storms by optimizing caching, throttling, and password hashing to achieve a 1000x reduction in tail latency The story begins with a customer-visible problem: node restarts spiked P99 latency to 5 seconds for a full minute, while typical latency for the cluster was only 4 milliseconds. The cause was a flood of new connections. Source

How ScyllaDB’s Trie-Based Index Delivers Up to 3X More Throughput

30 June 2026, 1:03 pm by ScyllaDB

By transitioning from separate summary and index files to a prefix tree, we optimized cache efficiency, reduced disk I/O, and reduced memory overhead Trie-based SSTable index format was added in ScyllaDB 2025.4. Since then, it has evolved and matured to become the default index format in ScyllaDB 2026.2. In this post, we deep dive into the format change, present its pros and cons… Source

ScyllaDB 2026.2: DynamoDB Streams and Vector Search, Trie Indexes, and Strongly Consistent Tables

29 June 2026, 7:18 pm by ScyllaDB

ScyllaDB 2026.2 brings a combination of GA new features, exciting experimental features, and multiple stability and external use case improvements. The updates include: 2026.2 is more stable, works faster, and better than any past release. You are encouraged to upgrade to it, and use it for any new deployment. For the full release notes, see this forum post. Alternator is a native… Source

Riding the Raft to Strong Consistency in ScyllaDB

24 June 2026, 4:51 pm by ScyllaDB

How ScyllaDB is using per-tablet Raft groups to bring strong consistency to data, without sacrificing the parallelism that makes it fast Distributed databases live in a world where failure is normal. Nodes fail. Networks could have partitions. Clocks might be different in each area that you’re working in. Messages can be delayed or never arrive because of the network itself. Source

Instaclustr product update: June 2026

18 June 2026, 12:00 pm by Apache Cassandra - Instaclustr

Here’s a roundup of the latest features and updates that we’ve recently released.

If you have any particular feature requests or enhancement ideas that you would like to see, please get in touch with us.

Major announcements AI Search for OpenSearch is now generally available on the NetApp Instaclustr Managed Platform

AI Search for OpenSearch is generally available on the NetApp Instaclustr Managed Platform. It brings semantic search, hybrid search, and retrieval-augmented generation (RAG) without the complexity of managing software, infrastructure, or operational management. General availability expands on the public preview, adding support for external LLM and embedding services such as Amazon Bedrock and OpenAI for enterprise search, e-commerce, support chatbots, and observability-style use cases. Unlock new possibilities with AI search—learn more.

Introducing Kafka Client Telemetry: Centralized client metrics for Instaclustr Managed Apache Kafka®

NetApp is introducing Client Telemetry for Instaclustr for Apache Kafka®, designed to deliver broker-integrated visibility into Kafka client and application-level metrics, with telemetry export and centralized collection. Instaclustr for Apache Kafka users can gain visibility into client behavior such as connection status, request rates, error rates, and latency from the broker, simplifying monitoring and supporting a holistic view of client interactions. Compliant Kafka clients collect metrics and push them to the brokers; brokers use an OpenTelemetry Collector to forward metrics to a customer-specified destination, with Prometheus 3.0+ and Datadog supported in this initial release.

Powering low-latency analytics with ClickHouse® and Amazon FSx

Instaclustr Managed ClickHouse integrated with Amazon FSx for NetApp ONTAP is built to run analytical queries directly on file-based data that can transparently tier to lower-cost capacity, without relying on extra staging layers, ingestion pipelines, or format-specific copies to make data queryable. The integration now supports deployments where compute and storage can reside in different VPCs or AWS accounts, enabling flexible, enterprise-grade architectures with consistent storage access across network and account boundaries.

Other significant changes Apache Cassandra®
  • Self-service iccassandra password reset — customers can now reset their iccassandra database password directly from the console via the Connection Info page, eliminating the need to raise a support ticket. The new password is displayed for 5 days before being automatically removed.
  • Released Apache Cassandra v4.1.10 into General Availability on the NetApp Instaclustr Managed Platform, delivering a stability-focused patch release, while deprecating Apache Cassandra 4.1.9.
Apache Kafka® ClickHouse® OpenSearch®
  • New c7g.8xlarge node size on the AWS provider has been added to support OpenSearch clusters.
  • OpenSearch 3.5.0 released to General Availability.
  • AI Search is now available on the free trial.
PostgreSQL® Instaclustr Managed Platform
  • The new AWS region, ap-southeast-6 (New Zealand), has been added.
  • Cluster tag management improvements — multiple enhancements to tag search, display, and validation in the console and API, including prevention of duplicate tag keys for better data consistency.
Future releases OpenSearch®
  • We’re preparing to introduce GPU nodes for OpenSearch on the NetApp Instaclustr Managed Platform, bringing dedicated machine learning capabilities directly into your managed clusters. With GPU nodes, vector indexing can be up to 10x faster and CPU load is reduced, freeing cluster capacity for mission-critical workloads. Additionally, GPUs offer superior cost-efficiency compared to traditional CPU-based vector indexing, driving down the total cost of ownership.
PostgreSQL®
  • We’re close to launching PostgreSQL® integrated with FSx for NetApp ONTAP (FSxN) into GA, now including NVMe support—designed to deliver improved throughput, up to 20% observed greater throughput than we achieved with our public preview. This enhancement combines enterprise-grade PostgreSQL with FSxN’s scalable, cost-efficient storage for better cost, performance, and flexibility, while enabling ONTAP snapshots for backups, mirroring, and multi-region recovery—fast snapshot/restore and daily backups for large databases.
MCP Gateway Service
  • NetApp Instaclustr plans to release the Remote MCP Gateway Service powered by AgentGateway on the Instaclustr Managed Platform. This service will let you, in minutes, provision and configure a production-ready Model Context Protocol gateway to provide LLM access to databases, application data infrastructure services, and REST APIs.
Instaclustr Managed Platform
  • Coming soon, NetApp Instaclustr will be launching the Self-Service Bring Your Own Cloud (BYOC) feature for AWS, offering a fully guided onboarding experience that allows customers to connect their AWS accounts and begin deploying managed clusters directly from the console — making it faster and easier for customers who prefer to run clusters in their own cloud environments.
    Cluster DNS will soon be available for Apache Cassandra and Apache Kafka clusters on AWS allowing you to connect to your applications using simple, stable hostnames instead of long lists of IP addresses. When node IPs change due to scaling, replacement, or maintenance there is no longer a need to update client configuration.
Did you know?

If you have any questions or need further assistance with these enhancements to the Instaclustr Managed Platform, please contact us.

SAFE HARBOR STATEMENT: Any unreleased services or features referenced in this blog are not currently available and may not be made generally available on time or at all, as may be determined in NetApp’s sole discretion. Any such referenced services or features do not represent promises to deliver, commitments, or obligations of NetApp and may not be incorporated into any contract. Customers should make their purchase decisions based upon services and features that are currently generally available.

The post Instaclustr product update: June 2026 appeared first on Instaclustr.

Automate ScyllaDB X Cloud Clusters with Terraform

16 June 2026, 12:27 pm by ScyllaDB

The ScyllaDB Cloud Terraform provider gives you infrastructure-as-code control over your clusters The ScyllaDB Cloud Terraform provider now supports ScyllaDB X Cloud. That means you can provision and manage elastic, autoscaling ScyllaDB clusters the same way you manage the rest of your infrastructure. The provider lives at . You need a ScyllaDB Cloud account and an API token from cloud. Source

ScyllaDB Customer Experience Spotlight: Faisal Saeed

11 June 2026, 12:01 pm by ScyllaDB

Welcome to the second installment of a new blog series introducing some of the experts you might encounter when you work with ScyllaDB. (In the first, we met Tyler Denton, Solutions Architect). Today we’re featuring Faisal Saeed, Principal Customer Engineer on the Customer Experience team here at ScyllaDB. He lives in Singapore and has been at ScyllaDB for more than 2 years. Let’s learn a… Source

ScyllaDB Operator 1.21 Release — with Oracle Kubernetes Engine (OKE) Support

10 June 2026, 4:03 pm by ScyllaDB

Introducing Oracle Kubernetes Engine support, stronger TLS, and a lighter dependency footprint ScyllaDB Operator 1.21.0 is now available. For background, ScyllaDB Operator is an open-source project that helps you run ScyllaDB on Kubernetes. It lets you manage ScyllaDB clusters deployed to Kubernetes and automate tasks related to operating a ScyllaDB cluster (e.g., installation… Source

Using Salting to Lower Latency for Large Blobs in ScyllaDB

2 June 2026, 3:00 pm by ScyllaDB

A modified salting technique that cuts P99 write latency 22x for large blobs Storing huge blobs in any database has always been, and still is, very challenging. Large allocations required for storing, reading, compacting, and repairing such cells always create significant pressure on the memory allocation sub-system. In addition, receiving a write request or sending a read response with a huge… Source

Dear cqlsh: Your dependencies were killing us (P.S. We rewrote you in Rust)

2 June 2026, 12:35 pm by ScyllaDB

A story of rewriting cqlsh in Rust…with Claude Code and a lot of planning Dear , I vouched for you. I told the team you were fine. I forked you, catered to you, vendored your dependencies and your dependencies’ dependencies. I patched things upstream that I knew you would never merge. I pinned your , re-pinned it after the OS upgraded, and explained to people (with a straight face) why that… Source

ScyllaDB Customer Experience Spotlight: Tyler Denton

28 May 2026, 5:28 pm by ScyllaDB

Welcome to the first installment of a new blog series introducing some of the experts you’re likely to encounter when you work with ScyllaDB. Tyler Denton is a Solutions Architect on the Customer Experience team here at ScyllaDB. He lives in Fort Myers Florida, USA. He’s been at ScyllaDB for about a year, Let’s get to know a little about Tyler… I’m a Solutions Architect… Source

What’s new in Cassandra® 6? A roundup of features for users and operators

14 May 2026, 12:36 pm by Apache Cassandra - Instaclustr

Apache Cassandra 6 is shaping up to be significant release as some of its biggest changes affect the core behavior of the database:

  • How metadata is coordinated
  • How Cassandra is moving toward broader transaction support via Accord protocol
  • How repair is scheduled, and
  • How operators inspect and manage the system.

Let’s focus on a few changes that stand out:

  • Accord transactions
  • Transactional Cluster Metadata (TCM)
  • Automated repair
  • Constraints framework
  • Zstandard dictionary compression, and
  • Cursor-based compaction improvements.

Taken together, these changes point to a version of Cassandra that is becoming more structured internally and easier to operate.

Accord transactions for ACID guarantees

Accord is a general-purpose transaction framework that uses a leaderless consensus protocol to have highly available transactions and is used in Cassandra 6. The goal is broader transactional support across multiple keys, with strict serializable isolation and without a central bottleneck.

This matters because multi-key consistency is hard to handle cleanly in application code. Once a workflow spans more than one partition, the application often ends up doing coordination work that really belongs in the database.

Accord enables ACID behavior on transactional tables, which lets developers coordinate multi-step, multi-partition changes with stronger correctness guarantees, reducing the amount of custom consistency logic they have to build in the application.

Including multi-partition, conditional work has historically been difficult to express cleanly in Cassandra. For operators, it signals that transactions are becoming a more important part of the platform and something to watch closely as Cassandra continues to mature.

Read our deep dive on Accord transactions here.

Transactional Cluster Metadata (TCM)

TCM changes how Cassandra coordinates cluster-wide metadata. TCM introduces a Cluster Metadata Service that keeps an ordered log of metadata changes and makes those changes visible in a more consistent, coordinated way. That includes things like membership, token ownership, and schema state.

This was introduced because Cassandra’s older model depended heavily on eventual consistency and the Gossip Protocol to spread metadata changes across the cluster. TCM is meant to make those changes more explicit, more ordered, and easier to reason about.

For operators, this is one of the biggest architectural shifts in Cassandra 6. It does not mean Gossip Protocol disappears everywhere, but it does mean Cassandra is moving away from Gossip as the primary way cluster membership, schema, and data placement changes are coordinated and made visible. For users, the result should be more predictable schema and topology operations.

Automated repair orchestration

Automated repair brings repair orchestration into Cassandra itself. Repair is the mechanism Cassandra uses to reconcile replicas over time so they stay consistent, and the goal is to make repair scheduling and coordination a built-in database service rather than something operators must orchestrate with external tools.

This was introduced because repair is essential, but historically it has placed a real burden on operators. Teams have had to build their own schedules, decide how to run repair safely, and keep it consistent over time.

For operators, automated repair could be one of the most practical changes in the release. It reduces manual coordination, supports full and incremental repair, adds useful safeguards, and makes repair easier to treat as a normal part of cluster maintenance—just like it has happened with major compactions with Unified Compaction Strategy in Cassandra 5. For users, it means a better chance that maintenance happens regularly and with fewer gaps.

At NetApp Instaclustr, our expert TechOps team already orchestrates laborious tasks like repair for our Apache Cassandra customers, ensuring their clusters stay online. Our platform handles the complexity so you can get up and running fast.

Constraints framework for data validation

The constraints framework lets Cassandra enforce more targeted validation rules as part of the table schema. It enforces them at write time instead of relying entirely on application code to reject invalid data. Some examples of constraints include: Scalar (>, <, >=, <=), LENGTH(), OCTET_LENGTH(), NOT NULL, JSON(), REGEXP().

A simple example of an in-line constraint:

CREATE TABLE users ( username text PRIMARY KEY, age int CHECK age >= 0 and age < 120 );

This was introduced because Cassandra already had some broad limits, but they were not very granular or expressive. The constraints framework gives teams a more precise way to protect the shape of their data and guard against bad writes from misconfigured clients.

Operators gain more control and better predictability around what gets written into the cluster. For developers, it means some validation can move closer to the schema instead of being duplicated across every service.

Zstd dictionary compression

Zstandard, or Zstd, dictionary compression extends SSTable compression by letting Cassandra use trained Zstd dictionaries for repetitive data patterns. Instead of relying only on generic compression, it can use a dictionary built from representative data to improve results.

This was introduced to primarily improve compression ratio while keeping the design manageable in production. It is recommended to use minimal dictionaries and only adopt new ones when they’re noticeably better.

This makes compression more configurable and more visible for operators. It adds training workflows, dictionary lifecycle management, and observability into dictionary size and cached dictionary memory usage. For users, the main benefit is better storage efficiency, because data with strong repeating patterns can compress better, leading to potential performance gains.

You can read more about the constraints framework and Zstd dictionary compression in our article detailing recent CEPs.

Cursor-based compaction improvements

Cursor-based compaction is a new low-allocation compaction path in Cassandra 6 that processes SSTable data in a more streaming-oriented way, using reusable cursor-like readers and writers instead of constantly creating large numbers of temporary in-memory objects. In practical terms, it is designed to reduce heap allocation and garbage collection overhead during compaction.

Compaction is one of Cassandra’s most important background processes, and when it becomes cheaper and more efficient, nodes can spend less time fighting garbage collection and less heap on temporary work. For operators, that can mean smoother performance and better efficiency on large datasets. For developers, it is mostly an under-the-hood improvement, but one that can help clusters behave more consistently under load.

Conclusion: A more manageable database

What stands out about Cassandra 6 is that many of its biggest changes are not isolated features. They reshape core parts of how Cassandra behaves and how it is operated.

Accord introduces a broader transactional model. TCM changes how metadata is coordinated. Automated repair brings a core maintenance task into the database. Constraints make schemas more defensive. Zstd dictionary compression improves how Cassandra approaches storage efficiency, and cursor-based compaction makes the system easier to run.

Taken together, Cassandra 6 focused on making the database more deliberate internally and more manageable operationally.

Stay tuned for a preview release of Cassandra 6 on the Instaclustr Platform!

Ready to get started?

If you want to experience the power of Apache Cassandra without the operational headache, we have you covered. If you are an existing customer and would like to try Cassandra 5 before 6.0 is released, you can spin up a cluster today. If you don’t have an account yet, sign up for a free trial and experience the latest generation of Apache Cassandra on the Instaclustr Managed Platform.

Read all our technical documentation here.

Discover the 10 rules you need to know when managing Apache Cassandra.

If you are using a relational database and are interested in vector search, check out this blog on support for pgvector, which is available as an add-on for Instaclustr for PostgreSQL services.

The post What’s new in Cassandra® 6? A roundup of features for users and operators appeared first on Instaclustr.

Apache Cassandra® 6 Accord transactions: What you need to know

24 April 2026, 12:00 pm by Apache Cassandra - Instaclustr

There have always been architectural trade-offs when considering a distributed database like Apache Cassandra versus a relational database. Cassandra excels at linear horizontal scalability, multi-region replication, and fault-tolerant uptime that relational systems couldn’t match. This comes at the expense of general-purpose ACID (Atomicity, Consistency, Isolation, Durability) transactions which allows the ability to express complex, multi-row operations with guaranteed consistency.

With Cassandra 6 on its way to general availability status (and an alpha already released), we’re approaching a turning point where we can revisit whether these trade-offs will still exist. The latest version delivers general-purpose ACID transactions through a new protocol called Accord. With Cassandra 6, those transactional guarantees will be native, without compromising Cassandra’s operational model or availability.

Transactions

In database parlance, a transaction says, “These operations belong together. They must all be applied, or none of them.” The classic example is a bank transfer. When you move money from one account to another, two things must happen: a debit and a credit. If the debit succeeds but the credit fails, money has disappeared. A transaction prevents this issue by guaranteeing the two operations are atomic, meaning they succeed or fail as a unit; combined with isolation, no other process can see an immediate or half-finished state.

Experiences like these depend on transactional guarantees at the data layer, which rely on ACID semantics, particularly atomicity and isolation, to prevent inconsistent intermediate states.

For most developers who have worked with relational databases, transactions are so fundamental they’re almost invisible. For Cassandra users, comparable guarantees across multiple partitions or tables historically required significant application-level coordination or weren’t natively supported.

Coordination at scale is fundamentally hard

Because Cassandra is designed to deal with data replication and scaling, coordinating atomic changes across multiple nodes is inherently challenging (e.g., decrement a balance here, increment one there). All participating replicas must agree on an order of operations. Distributed consensus protocols exist to solve exactly this, but prior approaches came with trade-offs.

Raft and Zab are examples of protocols that use leaders, which is not suitable for Cassandra since nodes are treated equally.

More information about prior solutions can be found in more details in CEP-15, but generally, leader-based approaches pose issues at scale.

The Accord protocol

The Accord protocol, proposed in CEP-15, is built to achieve fast, general-purpose distributed transactions that remain stable under the same failure conditions Cassandra already tolerates— with no elected leaders.

How it orders transactions

Accord is leaderless so any node can coordinate any transaction. Transactions are assigned unique timestamps using hybrid logical clocks, where each node appends its own unique ID to its clock value to ensure global uniqueness across the cluster. Conflicting transactions execute in timestamp order across all replicas. Under normal conditions, a transaction reaches consensus in a single round trip.

The reorder buffer

The challenge with timestamp-based ordering in a geo-distributed system is that two transactions started concurrently from different regions might arrive at replicas in different orders, breaking fast-path consensus. Accord solves this by having replicas buffer incoming transactions. The wait time is precisely bounded to be just long enough to account for clock differences between nodes and network latency, and no longer. This guarantees that replicas always process transactions in the correct order without needing extra message rounds.

Fast-path electorates

When replicas fail, other leaderless protocols fall back to slower, more expensive message patterns. Accord avoids this by dynamically adjusting which replicas participate in fast-path decisions as failures occur. The result is that Accord maintains fast-path availability under failure, avoiding the degradation to slower message patterns that other leaderless protocols experience.

The net effect: strict serializable isolation across multiple partitions and tables, in a single round trip, with no leaders, and preserving performance characteristics under the same minority‑failure conditions that Cassandra is designed to tolerate.

New CQL syntax to support transactions

The most visible change for developers is new CQL syntax. Transactions in Cassandra 6 are wrapped in BEGIN TRANSACTION and COMMIT TRANSACTION blocks, similar to SQL syntax.

Let’s examine a flight booking transaction that must simultaneously reserve a seat and deduct loyalty miles from two separate tables. Note: Cassandra 6 is pre-release. Syntax shown reflects the current alpha and may evolve before general availability.

BEGIN TRANSACTION LET seat = (SELECT available FROM flight_seats WHERE flight_id = 'ZZ101' AND seat_number = '14C'); LET miles = (SELECT balance FROM loyalty_accounts WHERE member_id = 'M-7823'); IF seat.available = true AND miles.balance >= 25000 THEN UPDATE flight_seats SET available = false, booked_by = 'M-7823' WHERE flight_id = 'ZZ101' AND seat_number = '14C'; UPDATE loyalty_accounts SET balance = miles.balance - 25000 WHERE member_id = 'M-7823'; END IF COMMIT TRANSACTION ;

Everything between BEGIN TRANSACTION and COMMIT TRANSACTION executes atomically with strict serializable isolation from the perspective of all other concurrent transactions. The LET clause reads current values from the database and binds them to variables. The IF block uses those values to guard the writes. If the seat is already taken or the member doesn’t have enough miles, nothing happens. Both updates either apply together or not at all, across two different tables and two different partition keys.

This is logic that previously had to live in the application, complete with retry handling, race condition guards, and compensating operations if something failed halfway through. Now it lives in the database.

Enabling Accord in Cassandra 6: The CMS dependency

We can’t talk about Accord without discussing Cluster Metadata Service (CMS). Before Accord transactions are functional, Cluster Metadata Service (CMS), introduced alongside Accord as CEP-21, must be enabled. For teams upgrading from Cassandra 5, this is the most significant operational change in the release.

CMS is required. Accord needs every replica to have the same authoritative view of cluster topology showing which nodes own which data, and which replicas participate in a given transaction. Before Cassandra 6, this information was propagated via the eventually consistent Gossip Protocol. This is suitable for normal reads and writes, but Accord’s correctness depends on knowing precisely who the transaction participants are before committing. CMS replaces Gossip-based metadata propagation with a distributed, linearized transaction log, giving all nodes a consistent view of cluster state. Without it, Accord’s guarantees don’t hold.

Upgrading from Cassandra 5 to 6—plan carefully

The upgrade cannot begin until every node in the cluster is running Cassandra 6. CMS initialization requires full cluster agreement; no mixed-version clusters are supported. Before upgrading, disable any automation that could trigger schema changes, node bootstrapping, decommissions, or replacements. These operations are blocked during the upgrade window, and if they fire on an older node before CMS is initialized, the migration can fail in ways that require manual intervention to recover.

Once all nodes are upgraded, run nodetool cms initialize on one node to activate CMS. This creates the service with a single member, which is enough to unblock metadata operations but is not suitable for production. Follow up immediately with nodetool cms reconfigure to add more members. CMS uses Paxos internally and requires a minimum of three nodes for a viable quorum, with more recommended for production depending on cluster size.

Important: CMS initialization is not easily reversible. Plan the upgrade window accordingly and treat it as a one-way operational step.

On a fresh Cassandra 6 cluster that wasn’t migrated from a previous version, CMS is automatically enabled. First, one node is designated as the initial CMS member. From there, CMS membership scales automatically based on cluster size, with the service adding members as the cluster grows without requiring manual intervention.

Of course, for Instaclustr users, our platform and techops team will take care of most of this for you and walk you through any requirements on your side when the time comes to upgrade.

Coexistence with Lightweight Transactions (LWT)

Existing LWT syntax (IF NOT EXISTS, IF EXISTS, conditional UPDATE/INSERT statements) continues to work and fundamentally differs from Accord transactions as LWT is scoped to a single partition and is extremely limited. Accord doesn’t replace or break existing applications. Using BEGIN TRANSACTION/END TRANSACTION is how developers opt into the broader cross-partition guarantees.

Why this is architecturally significant

Every prior approach to distributed transactions required accepting one of three constraints: a global leader (single point of failure, WAN latency penalty), limited to single-partition scope (LWT), or degraded performance under failure (prior leaderless protocols). The Accord paper’s central claim is that these constraints are not fundamental. They are artifacts of specific protocol design choices.

By combining flexible fast-path electorates with a timestamp reorder buffer on top of a leaderless execution model, Accord achieves:

  • True cross-partition atomicity across multiple tables and partition keys
  • Strict serializable isolation with formally proven correctness
  • Single round-trip latency under normal operating conditions
  • Failure‑tolerant steady‑state performance, avoiding the systematic degradation seen in earlier leaderless protocols
  • No elected leaders, consistent with Cassandra’s existing operational model

This opens workloads that were previously natively incompatible with Cassandra: financial transaction processing, distributed inventory reservation, multi-step workflow coordination, and any application where ‘commit these changes together or not at all’ is a strict correctness requirement.

Looking ahead

Though the Accord protocol is still maturing, the fundamental capability is finally here. We now have general-purpose, leaderless, multi-partition ACID transactions natively in Apache Cassandra.

The historically difficult problem of achieving strict serializable isolation in a geo-distributed system without compromising fault tolerance now has a proven, working answer.

For Cassandra users, this raises an exciting question: which workloads have you been routing to relational databases specifically because they needed transactional guarantees? It is time to reevaluate.

Stay tuned for a preview release of Cassandra 6 on the Instaclustr Platform and get ready to experience the power of ACID transactions on Cassandra for yourself!

The post Apache Cassandra® 6 Accord transactions: What you need to know appeared first on Instaclustr.