Explain the lifecycle of an SSTable in ScyllaDB?

An SSTable's life begins in memory and ends when its data is either merged into a newer SSTable or fully expired and removed.

Once a memtable fills past its threshold, ScyllaDB flushes it to disk as a new, immutable SSTable, complete with its own bloom filter (to quickly rule out SSTables that definitely don't contain a key) and index for locating rows within the file. As more SSTables accumulate from ongoing writes, the configured compaction strategy periodically selects a set of them to merge: overlapping row versions are reconciled (keeping the latest write, respecting tombstones), and a new, consolidated SSTable is written while the old input SSTables are deleted once the merge completes successfully. Fully-expired SSTables, where every row has passed its TTL and gc_grace_seconds, can sometimes be dropped entirely without a full merge, which is one reason time-bucketed compaction strategies like TWCS are efficient for TTL-heavy data.