State Backend Configuration
How Flink's state backend handles state TTL and expired-state cleanup, including GeminiStateBackend-specific behavior, across SQL, DataStream, and Python deployments.
This page covers how Flink's state backend handles state time-to-live (TTL) and expired-state cleanup. It applies to SQL, DataStream, and Python deployments alike.
State TTL Cleanup
table.exec.state.ttl sets how long a state entry stays valid before it becomes eligible for removal. In Apache Flink®, expired entries are always removed lazily on the next read or access, regardless of the state backend in use.
GeminiStateBackend honors Flink's per-state TTL configuration (StateTtlConfig). For DataStream and Python deployments, state.backend.gemini.ttl.ms sets a job-level default TTL that any per-state TTL configuration overrides.
Gemini's TTL behavior differs from RocksDB in two ways. Gemini never returns expired data, even if it hasn't been physically cleaned up yet, matching Flink's NeverReturnExpired state visibility. RocksDB can still return expired but not yet cleaned up data under ReturnExpiredIfNotCleanedUp. Gemini also only refreshes a state entry's TTL timestamp on write, matching Flink's OnCreateAndWrite update type. RocksDB can also refresh it on read (OnReadAndWrite), which Gemini doesn't support.