[RELEASE] ScyllaDB 2026.2

Release Notes
, , ,
1

The ScyllaDB team is pleased to announce the release of ScyllaDB 2026.2, a production-ready ScyllaDB Short Term Support (STS) Minor Feature Release.

More information on ScyllaDB Version Support Policy is available here.

Upgrade Paths

You can upgrade to 2026.2 from version 2026.1. See the Upgrade Guide from ScyllaDB 2026.1 to ScyllaDB 2026.2.

Related Links

Highlights

The highlights of the 2026.2 release:

  • Alternator Streams now Generally Available (GA), providing production-ready DynamoDB Streams-compatible change data capture for Alternator workloads.

  • In-memory CQL authentication and authorization cache, which reduces login latency and improves resilience in high connection-rate deployments.

  • Trie-based SSTable index format (ms) as the default for new SSTables, reducing the in-memory footprint of index data and improving index lookup performance.

  • Vector Search: Cassandra SAI compatibility, enabling LangChain, LlamaIndex, and CassIO applications to work with ScyllaDB without code changes.

New Features and Improvements

This section introduces the latest enhancements and refinements across ScyllaDB 2026.2.

Alternator: Streams Now Generally Available

Alternator Streams, ScyllaDB’s DynamoDB Streams-compatible change data capture interface, is now Generally Available (GA). Applications can capture ordered item-level changes from Alternator tables for event-driven architectures, CDC pipelines, and replication workflows.

Streams are now enabled automatically when Alternator is configured. The --experimental-features=alternator-streams flag is no longer required and can be removed after upgrade.

CQL: In-Memory Authentication Cache

A new full in-memory authentication and authorization cache is now available for CQL connections. Authentication and permission data is cached in memory and automatically synchronized when changes occur, reducing the need for synchronous reads from system auth tables during client login.

This reduces authentication latency, lowers load on system auth tables, and increases resilience during connection spikes or mass reconnect events common in Kubernetes and microservice deployments.

The feature is automatically enabled after upgrade and requires no configuration changes or user action.

CQL: Per-Row Time-to-Live (TTL)

ScyllaDB now supports automatic row expiration through a new per-row TTL feature for CQL. Unlike the existing per-write TTL (USING TTL), which applies a relative time-to-live at write time, per-row TTL stores an absolute expiration time in a dedicated column. When that time passes, the row is automatically deleted.
To designate a TTL column, use the TTL keyword in CREATE TABLE:

CREATE TABLE tab (
     id int PRIMARY KEY,
     t text,
     expiration timestamp TTL
);

Per-row TTL can also be enabled or disabled on an existing table with ALTER TABLE:
Enabling:

ALTER TABLE tab TTL expiration

Disabling:

ALTER TABLE tab TTL NULL

See Per-Row TTL in the ScyllaDB documentation for details.

Trie-Based SSTable Index Now Default

The trie-based SSTable index format (ms format) is now the default for newly written SSTables. The trie index is a tree-structured index format that reduces the in-memory footprint of SSTable index data and improves the performance of index lookups compared to the me format.

The charts below show the maximum read throughput for the old me SSTable format and the new ms format with tie index, under latency SLA, and the latency for the same run.

image
Throughput800×600 23.3 KB

image
Latency800×600 17.1 KB

When the cluster is configured to use the new ms format, existing SSTables are not rewritten automatically; they will be upgraded to the new format on the next compaction.

Alternatively, use nodetool upgradesstables -a to manually upgrade existing SStables.

:information_source: The new default format applies only to newly created clusters. Upgraded clusters will continue using their existing sstable_format configuration.

See SSTable ms Index: Trie-Based Format in the ScyllaDB documentation for more information.

Vector Search

ScyllaDB continues to expand its Vector Search capabilities with improved Cassandra compatibility, DynamoDB API support, and performance enhancements.

:information_source: Vector Search is available in ScyllaDB Cloud.

Cassandra SAI Compatibility for Vector Search

ScyllaDB now accepts Cassandra SAI-style vector index definitions and transparently maps them to ScyllaDB’s native vector indexing implementation. This enables applications built with LangChain, LlamaIndex, CassIO, and other Cassandra-compatible AI frameworks to work with ScyllaDB without code changes.

Example:

    CREATE CUSTOM INDEX ON my_keyspace.documents (embedding)

      USING 'StorageAttachedIndex'

      WITH OPTIONS = {

        'similarity_function': 'cosine',

        'source_model': 'openai-text-embedding-3-small'

      };

The feature is automatically enabled after upgrade and requires no configuration changes.

Alternator Support for Vector Search

Vector Search is now supported in Alternator, ScyllaDB’s DynamoDB-compatible API. Applications using the DynamoDB API can now run vector similarity search without requiring a separate search cluster.

Vector indexes can be created using the new VectorIndexes parameter in CreateTable, or added to an existing table with VectorIndexUpdates in UpdateTable. Searches are performed using the standard DynamoDB Query operation with the new VectorSearch parameter.

Vector indexes are supported on clusters using tablets-based data distribution.

See Alternator Vector Search in the ScyllaDB documentation for more information.

Vector Search Index Migration

Vector index rebuilds can now be performed without query downtime. A new index can be created on a column while the existing index continues serving ANN queries, and traffic automatically switches to the new index once it is ready.

This enables safe updates to vector index configuration, such as changing similarity settings or other index parameters, without interrupting availability.

See Altering a Vector Index in the ScyllaDB Cloud documentation for details.

Additional Vector Search Improvements

  • Fixed a performance regression affecting vector column access and vector similarity functions, restoring full performance for workloads that retrieve or compute on stored vectors.

  • Quantization and filtering follow-ups, including API usability improvements for filtering and quantization workflows.

Additional Improvements

Tablets

Support for Adding/Removing a Datacenter in Tablet Keyspaces

Tablet-enabled clusters now support adding or removing an entire datacenter by changing the replication factor from 0→N (add DC) or N→0 (remove DC). This simplifies multi-DC topology changes by handling tablet movement automatically through the load balancer.

-- Add a new datacenter

ALTER KEYSPACE my_ks WITH replication = {

    'class': 'NetworkTopologyStrategy',

    'dc1': ['RAC1', 'RAC2'],

    'dc2': ['RAC3', 'RAC4', 'RAC5']

};

-- Remove a datacenter

ALTER KEYSPACE my_ks WITH replication = {

    'class': 'NetworkTopologyStrategy',

    'dc1': ['RAC1', 'RACK2'],

    'dc2': []

};

See Data Definition and Rack-list Replication Factor in the ScyllaDB documentation for details about configuring the RF.

Counter Garbage Collection (GC) for Tablets

Counter shards belonging to decommissioned or outdated replicas are now garbage collected in tablet-based clusters. This reduces counter storage overhead and improves read performance predictability, especially in environments with tablet movement across nodes.

image
image1695×931 229 KB

Scheduling, Resource Management, and Storage

Nested Scheduling Groups

The scheduling system now uses a hierarchical model instead of a flat structure. Workloads are organized into supergroups that separate user traffic from maintenance operations such as compaction, streaming, and backups.

This improves resource isolation and ensures predictable performance even when multiple service levels or background tasks are active, preventing maintenance workloads from interfering with user queries.

To control the impact of background work, a new cluster-wide maintenance_io_throughput_mb_per_sec parameter is introduced. This setting limits the total I/O throughput available to the maintenance supergroup, which allows you to cap background activity and preserve resources for user workloads. It replaces the previous streaming-specific throughput limit and applies consistently across all maintenance activities.

Replica-Side Load Shedding

Read requests are now proactively dropped at overloaded replicas when they are unlikely to complete within their timeout window. This prevents wasted CPU and I/O on work that would otherwise be discarded and avoids saturation collapse under heavy load or partial node failures.

The preemptive_abort_factor parameter controls when requests are preemptively rejected.

The mechanism is automatically enabled after upgrade.

The following illustrative diagram shows the expected system behavior under overload conditions. It is intended to aid conceptual understanding and is not based on benchmark or production measurements.

image
image1694×932 250 KB

Repair: Tombstone GC Optimization for Incremental Repair

Tombstone garbage collection in repair mode has been optimized for incremental repair workflows. Previously, tombstone GC checked all SSTables (repaired, repairing, and unrepaired) when determining whether tombstones could be safely removed, which added unnecessary overhead.

The logic now only considers the repaired SSTable set, since incremental repair guarantees that all relevant data has already been moved before tombstones become eligible for garbage collection. This reduces redundant work without affecting correctness.

This optimization is automatically enabled after upgrade for tables using tablets and repair mode (tombstone_gc = {'mode': 'repair'}).

Guardrails: Write Consistency Level Restrictions

The guardrail system has been expanded to cover additional potentially unsafe configuration options, helping reduce the risk of misconfiguration in production clusters.

New controls allow operators to monitor, warn, or block writes using weak consistency levels such as ANY, ONE, or LOCAL_ONE, which may not guarantee durability under failure scenarios.

Example configuration:

guardrails:

  write_consistency_levels_warned:

    - ANY

    - ONE

  write_consistency_levels_disallowed:

    - ANY

These new guardrails are not enabled by default and must be explicitly configured. The new scylla_cql_writes_per_consistency_level metric can help you first audit the actual distribution of write consistency levels in their workloads before enabling enforcement.

The new metric is always incremented, even when guardrails are disabled, allowing you to audit the actual distribution of write consistency levels prior to enabling enforcement. This is particularly useful when considering the warning guardrail, which may introduce additional traffic and reduce throughput.

Oracle Cloud Infrastructure (OCI) Support

Oracle OCI Object Storage

ScyllaDB can now use OCI Object Storage via its S3-compatible API without any special configuration beyond specifying the correct endpoint.

OCI S3-compatible endpoints follow this format:

https://<namespace>.compat.objectstorage.<region>.oci.customer-oci.com:443

Where <namespace> is the OCI Object Storage namespace and <region> is the OCI region (for example, us-ashburn-1).

This update enables the use of OCI as the keyspace backend storage provider, as well as for backup and restore operations within the cluster.

See Using Oracle OCI Object Storage in the ScyllaDB documentation for details.

VM.DenseIO.E5 Instance Tuning

We’ve added support for VM.DenseIO.E5 instances by tuning and performance testing them extensively. IO tuning now recognizes those instances and tunes ScyllaDB when running on them.

Vnodes to Tablets Migration (Experimental)

You can now migrate existing keyspaces from vnode-based to tablet-based data distribution online, with no significant performance degradation under live read/write workloads.

This first milestone supports:

  • Multi-node clusters, single datacenter.

  • CQL-based tables.

  • Online migration — reads and writes continue during the process.

  • Degraded operation with one node down (requires read-repair).

  • Rollback of an in-progress keyspace migration.

  • Observability — node-level resharding progress and cluster-level migration status are exposed.

Limitations in this milestone: per-table migration, topology changes during migration (bootstrap, decommission, removenode, replace), schema changes on migrated tables (ALTER/DROP KEYSPACE or TABLE, TRUNCATE), Materialized Views, Secondary Indexes, LWT, CDC, Counters, Alternator, Vector Search, Hinted Handoff, and Backup/Restore are not supported while a migration is in progress.

See Migrate a Keyspace from Vnodes to Tablets in the ScyllaDB documentation for details.

Strong Consistency: Raft Group per Tablet (Experimental)

This release introduces the foundational infrastructure for strongly consistent tables. Strong consistency guarantees that every read reflects the most recent committed write. Each tablet now maintains its own Raft consensus group, enabling serializable reads and writes within a tablet.

This release implements global strong consistency (a single Raft group per tablet operating across all datacenters) and makes it available for evaluation and testing purposes. Support for local (per-DC) strong consistency is not yet available.

This is an experimental feature and must be explicitly enabled via the strongly-consistent-tables experimental flag:

experimental_features:
- strongly-consistent-tables

Once enabled, you can create a strongly consistent keyspace:

CREATE KEYSPACE my_keyspace

    WITH consistency = 'global';

Limitations: Strongly consistent keyspaces currently do not support LWT, CDC, Materialized Views, or Secondary Indexes.

Testing status: The feature is not yet fully tested, and production performance characteristics are still being evaluated.

To learn more about consistency, see:

1 Like
[RELEASE] ScyllaDB 2026.2.1