[RELEASE] ScyllaDB 2026.3.3

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

Compaction

  • nodetool stop COMPACTION no longer stopped major compactions, so you could only stop a running major compaction through the REST API. nodetool stop COMPACTION now stops both regular (automatic) and major compactions again. A new REGULAR type stops only regular compactions (nodetool stop REGULAR), and MAJOR stops only major compactions. nodetool and the REST API now share the same compaction-type validation, so nodetool rejects an invalid type right away with a clear error message. scylladb#31189

  • When a row had a shadowable tombstone and a regular tombstone with timestamps in different time windows, the timestamp-based splitting writer wrote both into the same time window. This could cause Time Window Compaction Strategy (TWCS) reshape to repeat endlessly. Each tombstone part is now written to the time window that matches its own timestamp, so reshape finishes as expected. scylladb#31833

  • If a node shut down early during startup, before compaction was enabled, the compaction manager’s shutdown path could leave a configuration-update action running. It could also let a late disk-space-monitor callback re-enable the compaction manager while it was stopping. Shutdown now drains that action and moves the compaction manager into its stopped state, so a node stops cleanly after an early startup error. scylladb#31648, scylladb#30832

CQL

  • SELECT ... FROM MUTATION_FRAGMENTS(<table>) ignored GROUP BY and returned one row aggregated over all fragments instead of one row per group. Aggregates over more than one internal page also came back as several partial rows. For example, a COUNT over 25,000 fragments returned 10000, 10000, and 5000. Aggregate and GROUP BY queries on MUTATION_FRAGMENTS() now page and group correctly and return the expected results. scylladb#31683

Materialized Views (MV)

  • The view building worker kept references to the staging sstables registered with it. When incremental repair or a tablet merge rewrote one of those sstables, the worker kept retrying view updates from the outdated sstable and never completed them. The worker now looks up staging sstables in the table’s current sstable set when it processes them, so view building continues correctly alongside incremental repair and tablet merges. scylladb#31512

Reliability

  • In rare cases, a commitlog segment allocation that had timed out could still complete after another segment was already active. This left a segment that could not be released, and repeated occurrences could stall writes, especially with large allocations. The commitlog now detects and handles this case, so segments are always released. scylladb#31620

  • When commitlog replay encountered damaged segments, the cache for large (fragmented) commitlog entries could mix fragments from different shards, because fragment IDs are only unique per shard. The cache is now kept per shard, so large entries are replayed correctly. scylladb#31793

Repair

  • Aborting a removenode operation didn’t reach its streaming phase, so the streaming kept running after the abort. An abort requested before streaming began was also lost. Both are now forwarded to the removenode streaming, so the operation stops promptly when you abort it. scylladb#31849

Stability

  • Some internal queries in system tables, such as lookups in system.repair_tasks and system.topology_requests, put parameter values directly into the query text. Each distinct value was cached as a separate prepared statement that was never evicted, so memory use grew steadily over time on long-running nodes. These queries now use bound parameters, which keeps the internal statement cache bounded. scylladb#31739

  • Dropping a table that has CDC enabled, or a tablets-based table that has used LWT, could trigger nested schema-change notifications that the notifier doesn’t support. If a listener was being unregistered at the same time (for example, during shutdown), the operation could hang. These paths now use the nested-safe notification calls, so DROP TABLE and ALTER TABLE work reliably in these cases. scylladb#29398

Storage

  • Each node keeps all of its user keyspaces either locally or in object storage, but this was not enforced. CREATE KEYSPACE now rejects a keyspace whose storage type differs from the cluster’s existing user keyspaces, and Alternator’s CreateTable returns a ValidationException on an object-storage cluster. Clusters that already mix storage types keep working and get a warning. You can relax this check with the new live-updatable restrict_mixed_storage_clusters option (true (default), warn, or false). Enforcing this prevents configurations that Scylla Manager backup and size-based tablet load balancing don’t support. scylladb#31397

  • A backup task still waiting for the snapshot lock ignored abort requests. It kept running, then started uploading after the Scylla Manager run that created it had stopped. Over time this could build up a large queue of leftover backup tasks on a node. Queued backup tasks now respond to abort, so stopping a backup run also cancels its pending tasks. scylladb#31706

  • The S3 chunked download path retried errors immediately without pacing, and retried non-retryable errors indefinitely, which could leave a read waiting forever. It also didn’t report refusals to the request throttling controller. Downloads now use the standard retry strategy with backoff and a bounded number of retries, and report to the throttling controller. Reads from object storage now behave predictably when the endpoint is under pressure. scylladb#31674

  • During sstable directory processing, such as a nodetool refresh that needs to change sstable levels, one shard could claim an sstable another shard was still creating and schedule its components for removal. Each shard now handles only sstables that are fully created, so refresh completes reliably and keeps all sstables. scylladb#31474

Tablets

  • A DROP KEYSPACE or DROP TABLE that ran while tablet migration was streaming sstables into the same table could lead to a node restart. Streaming now holds the table for the duration of the operation, so the drop waits for in-flight streaming to finish. scylladb#31812

  • When the tablet load balancer planned a group of migrations, it checked the per-shard streaming limits using the number of migrations rather than their combined streaming weight. Rebuild migrations carry a higher weight, so source and target shards could go over tablet_streaming_read_concurrency_per_shard. The check now uses the combined weight, so streaming stays within the configured limits. scylladb#31811

  • The streaming concurrency cap for replication-factor-change rebuilds, introduced in 2026.3.2, has been reverted because it could delay rebuilds indefinitely in some topologies. RF-change rebuilds behave as they did before 2026.3.2. scylladb#31932