[RELEASE] ScyllaDB 2026.3.2

[Anna]

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

More information on ScyllaDB Version Support Policy is available here.

Related Links

• Get ScyllaDB 2026.3

• Upgrade ScyllaDB 2026.3 (Patch Upgrade)

• Contact our Support Team

Bug Fixes

The following issues are fixed in this release.

Alternator

• When a request was rejected for exceeding the per-shard concurrent-request limit (answered with RequestLimitExceeded), the connection could be closed even though the response had promised to keep it alive. A later, unrelated request that reused the same connection then failed with an unexpected disconnect. Rejected requests now leave the connection reusable, so clients no longer see spurious disconnects after hitting the concurrency limit.
  scylladb#31511

• Disabling Streams on a table keeps its CDC data readable for 24 hours by retaining the underlying CDC log table, but ListTables incorrectly listed that retained log table (<table>_scylla_cdc_log) as if it were a regular table. ListTables now excludes retained CDC log tables, so it only returns the tables an application actually created.
  scylladb#31747

Compaction

• Setting a Leveled Compaction Strategy sstable_size_in_mb above the 32-bit range in CREATE TABLE or ALTER TABLE passed validation but could later crash the node during schema commit. Such out-of-range values are now rejected up front.
  scylladb#31694

• In a related case, a newly produced SSTable could be picked up and removed by a second, unrelated compaction before the first compaction had finished with it, leading to the same “Unable to remove input SSTable” failure. Such SSTables are now protected from concurrent compaction until the first compaction releases them, closing this window.
  scylladb#31716

CQL

• Tracing a statement that bound a null element inside a collection (for example a list or set) could crash the node. A null collection element is now rendered as null in trace output, matching the JSON output behavior, so tracing such statements is safe.
  scylladb#31606

• With the TABLETS_ROUTING_V2_EXPERIMENTAL protocol extension enabled, a single-partition QUERY request could be incorrectly rejected. Such requests are now accepted under this extension.
  scylladb#31601

• With a prepared ALTER TABLE, CREATE INDEX, CREATE MATERIALIZED VIEW, or ALTER MATERIALIZED VIEW statement, if the first execution failed, later executions of the same prepared statement skipped part of the table-property validation, allowing invalid options (such as an invalid compaction strategy) to be accepted. Property validation now runs on every execution, so invalid options are consistently rejected.
  scylladb#31607

• A SELECT that combined a tuple range restriction on clustering columns with filtering could return wrong results when those clustering columns were declared with DESC (descending) order. Without a secondary index the query returned no rows; with a secondary index it could return exactly the rows that should have been excluded. Such queries now return the correct rows regardless of the clustering order.
  scylladb#31690

• A CREATE MATERIALIZED VIEW, ALTER MATERIALIZED VIEW, or CREATE INDEX statement that set an invalid compaction sub-option was not checked when the statement was prepared, so it could crash the node during schema commit, and afterwards the affected view could not be dropped through CQL. Compaction sub-options for views and indexes are now validated up front, the same as for tables, and options unknown to the chosen compaction strategy are also rejected.
  scylladb#31694

Materialized Views (MV)

• After a node restart, the view builder could resume building an unfinished materialized view without first flushing its base table, on the assumption that the flush had already happened. When that assumption did not hold, some view updates could be missed, leaving the view out of sync with its base table. The base table is now always flushed when the view builder resumes building an existing view, so no updates are lost.
  scylladb#31587

Repair

• A long-running user-requested repair on a vnode keyspace could block a concurrent topology operation (such as a decommission) until the node running the repair was restarted. Topology operations now abort such repairs so they can proceed; the aborted repair can simply be re-run afterwards.
  scylladb#31419

• A non-numeric value for the ranges_parallelism repair option was silently treated as 0, which caused the repair to hang forever. Invalid and out-of-range values (below 1) are now rejected immediately with a clear “bad parameter” error instead of hanging.
  scylladb#31622

Storage

• Truncating a table on a disk that had run out of free commitlog space could hang indefinitely, because the truncate disabled the very compaction it needed to free that space before flushing. The ordering is now corrected so the truncate can complete instead of stalling.
  scylladb#31470

• On object-storage-backed keyspaces, if wiping an SSTable’s objects failed, the SStable’s registry entry could still be marked as deleted while its objects remained, so later garbage collection would miss them and leak storage. The SSTable is now left intact on such a failure instead of being marked deleted, so it can be retried and cleaned up.
  scylladb#31413

• A backup to an S3 endpoint that was throttling requests (for example under load-shedding) could exhaust its retries and fail the whole multipart upload, surfacing as a confusing “Failed to parse ETag list” error rather than indicating that the endpoint was overloaded. Backups now detect sustained throttling and briefly pause instead of adding more load, and use a longer retry backoff for throttling responses, making backups against a busy endpoint more resilient.
  scylladb#31605

• An upload to Google Cloud Storage (GCS) could silently lose data when a chunk upload received a 308 response with no Range header, which the client wrongly took as confirmation that the chunk was not persisted and skipped resending it, finalizing the upload at a size that was never fully written. The client now queries the upload status explicitly in this case, so the chunk is not skipped and the data is not lost.
  scylladb#31675

• Restoring from an older backup manifest that did not include certain optional SSTable fields failed because the loader required those fields to be present. The optional fields are no longer required, so restoring older backups works again.
  scylladb#31704

• A backup could, in rare cases, crash the node if the table or keyspace being backed up was affected by concurrent activity during the upload. Backups now handle this safely and no longer risk crashing the node.
  scylladb#31713

Tablets

• When estimating table sizes to plan a migration from vnodes to tablets, a node measured its on-disk size from a single shard and scaled it using primary token ownership, which underestimated the true size and was inaccurate for clusters with unevenly sized racks. This could cause the migration to choose too few tablets. Table size is now estimated by summing across all shards and using replica ownership, giving a more accurate tablet count.
  scylladb#31658

• After a tablet split or merge, tablet migration could stall for up to 60 seconds (until the next periodic load-stats refresh) if a replica had not yet reported its size, for example a node that had just joined. A load-stats refresh is now triggered immediately in this case, so migration no longer waits.
  scylladb#31659

• During a replication-factor change, streaming from the source replicas was not counted against the per-shard streaming limit (tablet_streaming_read_concurrency_per_shard), so a single source shard could be asked to stream an unbounded number of tablets at once, overloading it. The per-shard streaming limit is now enforced consistently across all replicas involved, keeping streaming load bounded.
  scylladb#31689

• During a tablet-aware restore, a table’s original tablet settings could be permanently lost if the node driving the restore was lost mid-restore, because those original values were only held in that node’s memory; re-issuing the restore from another node then read the already-pinned settings as if they were the originals. The original settings are now persisted before the restore pins them, so a restore that resumes on another node recovers the correct values.
  scylladb#31676

Topology

• Restoring SSTables with load_and_stream could flood the cluster’s topology request queue, because each shard independently issued an expensive cluster-wide topology check, so a single call produced as many of these checks as the node has shards. These checks are now coalesced into one per call, avoiding the overload.
  scylladb#31490

• A coordinator that lost leadership mid-operation could still complete a TRUNCATE or SNAPSHOT, in rare cases using state belonging to a different, later operation. This could let a replica execute a request that had already been finalized elsewhere, risking data loss. Such operations are now safely aborted when the coordinator is no longer valid, preventing this.
  scylladb#31414

• A node that fell behind in applying incoming cluster-membership (gossip) updates could accumulate an unbounded backlog of duplicated pending updates from its peers, eventually exhausting memory. Pending updates are now coalesced to at most one per node, so the backlog is bounded by the size of the cluster rather than by the volume of gossip traffic.
  scylladb#31405