Build Durable Chat Memory for RAG Using ScyllaDB and LangChain
How to replace LangChain’s in-memory chat history with ScyllaDB — so your RAG chatbot retains context across restarts and scales across replicas This post demonstrates how to integrate ScyllaDB Vector Search into your LangChain project for RAG use cases, as well as how to use ScyllaDB as a durable conversation memory within LangChain. Large language models are trained on a fixed snapshot of… SourceScyllaDB Is Now Supported in MCP Toolbox for Databases
Connect your AI agents to ScyllaDB using the new ScyllaDB integration in MCP Toolbox for Databases ScyllaDB is now a supported database source in MCP Toolbox for Databases (as of v1.5.0). This means that your agents and applications can query your ScyllaDB clusters using the same framework they use to connect to Postgres, MySQL, BigQuery, and dozens of other databases. This post walks through… SourceAgent Memory at Monster Scale with Mem0 and ScyllaDB Cloud
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… SourceWhat’s Coming in Cassandra? Key Apache Cassandra CEPs to Watch
IntroductionApache 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: CQL Management API
- CEP-45: Mutation Tracking
- CEP-49: Hardware Accelerated Compression
- CEP-60: Flexible Placements
- CEP-62: Configuration Management via Sidecar
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 consistencyWhat 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 compressionWhat 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 balancingWhat 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 SidecarWhat 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.
ConclusionAltogether, 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.