[RELEASE] ScyllaDB 2026.1.13

Release Notes
, ,
1

The ScyllaDB team is pleased to announce the release of ScyllaDB 2026.1.13, a production-ready patch release for ScyllaDB 2026.1 Long Term Support (LTS) Release.

More information on ScyllaDB Version Support Policy is available here.

Related Links

Bug Fixes

The following issues are fixed in this release.

Compaction

  • During a tablet migration, a compaction group created while a tablet was being split could re-enable tombstone garbage collection even when it had been disabled to protect data that was still being streamed in. In rare cases this could cause already-deleted data to briefly reappear (data resurrection). New compaction groups created during a split now inherit the correct setting, closing this window.
    scylladb#31212

  • Reads using Time Window Compaction Strategy (TWCS) in reverse order could incorrectly skip some SStables that actually held matching rows, causing those rows to be missing from the query results. This affected only reversed-order reads on TWCS tables. The SStable filtering is now correct, so reversed TWCS reads return complete results.
    scylladb#31249

Materialized Views (MV)

  • A newly flushed SStable waiting to be processed for view building could, in rare cases, be missed and left unprocessed. When this happened, view updates for the data in that SStable were never generated, and the SStable stayed in the staging directory, leaving the affected materialized view out of sync. Every staged SStable is now reliably picked up for view building.
    scylladb#31222

Logging

  • Session-closing was logged at a high verbosity level left over from an earlier investigation, adding noise to normal operation. The routine session-closing message has now been lowered to a less verbose level, while a warning is still emitted for sessions that stay open for more than 5 minutes.
    scylladb#31363

Raft

  • In rare cases, truncating the Raft log could cause the cluster to lose track of an earlier cluster configuration still present in the log and fall back to an outdated one (for example, a snapshot could be stamped with a stale configuration). This was primarily observed as a rare internal inconsistency in configuration tracking. Configuration tracking now stays consistent after log truncation.
    scylladb#31257

  • Gracefully shutting down a cluster leader node could, in rare cases, leave it still counted as a voter after it had left the cluster. Because the vote count no longer matched the remaining nodes, this could lead to a loss of Raft quorum, which affects topology and schema changes. The departing leader is now correctly excluded, preventing quorum loss during graceful shutdown.
    scylladb#31280

CQL

  • A PREPARE statement running concurrently with a USE statement on the same connection could race over the connection’s state, which in rare cases corrupted an internal value and caused the node to restart. The connection state is now handled safely so this race can no longer occur.
    scylladb#31396

  • Altering a keyspace to use rack-list replication could hang indefinitely (livelock) when a target rack had no available nodes, for example a node that was stopped and excluded: the request would repeatedly pause and resume without making progress. Such a request now fails immediately with a clear error instead of looping forever.
    scylladb#31335

  • A connection registered by a driver as a control connection could later be reused for regular user requests, but would keep running in the scheduling group reserved for control traffic. This meant user requests on such connections were not scheduled and accounted for like normal user traffic. Connections are now reclassified as regular user traffic once they are used for user requests, keeping scheduling groups aligned with actual usage.
    scylladb#31180

Object Storage

  • The limit on how many object-storage (S3) multipart uploads run in parallel is now enforced reliably. Previously the limit was maintained indirectly and could, in principle, drift; there is no user-visible behavior change, but the concurrency bound is now an explicit, dependable property of the S3 client.
    scylladb#31310

  • Object storage resource usage (upload/download concurrency, connection pooling, and buffer budgets) is now easier to control and tune. Previously these limits were either indirectly derived, not tunable, or hard-coded. A new object_storage_connections_per_shard configuration option (default 128, live-updatable) gives each shard a tunable connection budget, letting operators directly manage object-storage resource usage under load.
    scylladb#31310

  • The first write to a table backed by Google Cloud Storage (GCS) could fail because of an invalid request sent when finalizing an empty upload, which GCS rejects. Because every object-storage SStable begins with an empty marker object, this made GCS-backed keyspaces effectively unusable. Empty uploads are now finalized correctly, so GCS-backed tables work as expected.
    scylladb#31255

Tablets

  • During a rack-list replication-factor change, new replicas on a node were all placed on a single shard instead of being spread across the node’s shards. This slowed down replication-factor changes and triggered extra internal data movement (intra-node migrations) to rebalance afterwards. Replicas are now spread across the node’s shards as intended.
    scylladb#31154