platinumhamburg opened a new issue, #3620: URL: https://github.com/apache/fluss/issues/3620
### Search before asking - [x] I searched in the [issues](https://github.com/apache/fluss/issues) and found nothing similar. ### Motivation Primary-key tables often keep the latest value for each key, but many workloads only need those values within a bounded lifetime. Without table-level row TTL, users must either issue explicit deletes, maintain cleanup jobs, or tolerate unbounded KV state growth. This is inefficient for common use cases such as session state, device heartbeat state, deduplicated event state, and temporary lookup dimensions. Fluss should provide a native row-level TTL mechanism so stale KV rows can be cleaned up automatically with clear, best-effort semantics. ### Solution Primary-key tables need a built-in row-level TTL mechanism to clean up stale KV rows without requiring explicit delete traffic. The first phase should provide best-effort cleanup semantics backed by RocksDB TTL. Introduce a table-level row TTL capability for primary-key tables, configured by `table.row.ttl`. When enabled, Fluss treats expired KV rows as eligible for background cleanup rather than requiring foreground delete writes. The first phase focuses on processing-time TTL with best-effort cleanup. It uses the underlying RocksDB TTL mechanism for efficient storage-level expiration, which avoids adding delete records to the write path and keeps the initial implementation lightweight. Expiration is therefore cleanup-oriented: data may remain visible until RocksDB compaction or reopen behavior makes the cleanup effective. The design also records row TTL storage metadata at table creation time. This makes the storage contract explicit and ensures all KV open/read/recovery paths know whether the table must be opened with TTL-compatible RocksDB behavior. This is important because RocksDB TTL changes the physical value layout internally. Future event-time TTL can be introduced through `table.row.ttl.time-column`, but it should use a Fluss-managed value layout and Fluss-owned expiration logic rather than RocksDB `TtlDB`. To keep that migration path clean, the first phase reserves the configuration and storage-mode concepts but rejects unsupported future modes explicitly. CDC delete output is not part of the first phase. The initial semantics are best-effort cleanup only, with no generated delete changelog for TTL expiration. A future phase can add explicit CDC semantics once Fluss owns the expiration decision and value layout. ### Anything else? _No response_ ### Willingness to contribute - [x] I'm willing to submit a PR! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
