[RELEASE] ScyllaDB 2026.3.4

Release Notes
, ,
1

The ScyllaDB team is pleased to announce the release of ScyllaDB 2026.3.4, 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

Bug Fixes

The following issues are fixed in this release.

Audit

  • Audit writes used timeouts of up to one hour. If a replica did not respond to an audit write (for example, during a rolling upgrade), topology operations could stall for that long, and a joining node could remain in the bootstrap state. Audit writes now use the same five-second timeouts as tracing writes, so topology operations continue promptly.
    scylladb#32315

Compaction

  • With Leveled Compaction Strategy (LCS), a table with a small amount of data waiting to be compacted could be reported as having no pending compactions. This pending work is now counted, so nodetool compactionstats and tools that rely on it correctly report outstanding compaction work. Compaction behavior itself is unchanged.
    scylladb#32042

  • If an incremental compaction was interrupted at its final step (for example, by a concurrent tablet split or migration), an unused temporary SSTable could remain on disk until the next restart. Such SSTables are now removed even if the compaction does not complete, so disk space is reclaimed promptly.
    scylladb#31884

  • When a keyspace was dropped shortly before a node was stopped, an error during shutdown could interrupt the schema change and, in some cases, cause the node to restart. Nodes now shut down cleanly in this scenario.
    scylladb#32199

Reliability

  • When a write timed out on a remote replica, the client received a WriteFailure error, whereas the same timeout on the coordinator’s own replica returned WriteTimeout. Because drivers retry WriteTimeout but not WriteFailure, such writes were not retried. Clients now consistently receive a retryable WriteTimeout error in both cases.
    scylladb#32208

Repair

  • A full incremental repair could temporarily treat already-repaired data as unrepaired. With tombstone_gc = {'mode': 'repair'}, this could cause a tombstone to be purged too early, so deleted data could reappear. Full incremental repair now leaves already-repaired data unchanged.
    scylladb#32008

  • During a graceful shutdown, a node coordinating a row-level repair of a table on object storage could restart unexpectedly. Shutdown now stops the repairs the node coordinates and waits for them to finish, so nodes shut down cleanly while repairs are running.
    scylladb#32295

  • Before a repair, a node replays pending hints and batchlog entries. Batchlog replay had no time limit, so if it stalled, every later repair on that node was blocked until the node was restarted. Batchlog replay now has a timeout, like hints replay, so later repairs can proceed.
    scylladb#32314

Stability

  • Under rare timing conditions, the commitlog could process its segments out of order. Segment ordering is now preserved, which improves commitlog stability.
    scylladb#31765

  • An error while processing a gossip update (for example, under memory pressure) could leave a node with incomplete information about another node, which gossip did not correct afterwards. Incomplete updates are now discarded and the full state is received again, so gossip state stays consistent across the cluster.
    scylladb#31980, scylladb#31979

Storage

  • Streaming, repair, and scrub could report a malformed SSTable if the SSTable was moved out of staging at the same time and, with abort_on_malformed_sstable_error enabled, restart the node. Streaming, repair, and scrub now work reliably while SSTables are moved out of staging.
    scylladb#32150

  • Reads from object storage did not correctly handle responses that were shorter than requested or that returned the whole object instead of the requested range. Such responses are now handled correctly, so reads of SSTables on object storage, including encrypted SSTables, are accurate.
    scylladb#32296

  • When a read from Google Cloud Storage was interrupted and retried (for example, after a topology change), the retry could restart from the beginning of the object instead of resuming at the current position. This could cause checksum mismatches when reading SSTables, and incorrect decryption with encryption at rest. Retried reads now resume at the correct position.
    scylladb#32308

  • Deleting SSTables on object storage could permanently reduce the number of connections available to user workloads. These deletions now run as maintenance work, so connection capacity for user workloads is preserved. Deletions are reported under the maintenance class in the s3 and object_storage metrics.
    scylladb#32298

  • If an error occurred during an S3 multipart upload, some of the upload’s resources were not released. These resources are now released when an error occurs.
    scylladb#32317

  • ScyllaDB now stores the version and format of each SSTable on object storage together with the SSTable. As a result, scylla-sstable can open SSTables on object storage directly, and GET /storage_service/object_storage/sstables reports each SSTable’s version and format.
    scylladb#31435

Tablets

  • During a vnodes-to-tablets migration, upgraded nodes could send tablet routing information to drivers before the migration was finalized. If the migration was then rolled back, drivers could continue routing requests based on tablets that no longer existed. Tablet routing information is now sent only after the migration is finalized. Until then, drivers route requests as they did before the migration, and a rollback requires no changes on the client side.
    scylladb#32099

Topology

  • A topology request could briefly be reported as completed before the node had applied the change locally. Completion is now reported only after the node has applied the change, so status APIs consistently reflect the node’s actual state.
    scylladb#32066