You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had searched in the issues and found no similar issues.
Description
Currently, Apache Doris relies exclusively on dynamic partitions for data lifecycle management on aggregate model tables. Row-level TTL can help to improve query performance and reduce storage consumption.
Use case
Row-level TTL targets scenarios that require data expiration based on non-partition columns. It is applicable to date-range partitioned tables, LIST partitioned tables, and non-partitioned tables. Row-level TTL can work either with or without when Dynamic Partitioning is enabled.
Use Case:
CREATETABLEexample_db.example_tbl
(
k1 DATE,
k2 INT,
k3 SMALLINT,
v1 VARCHAR(2048),
v2 DATETIME DEFAULT "2014-02-04 15:36:00"
)
PARTITION BY RANGE (k1) ()
DISTRIBUTED BY HASH(k2) BUCKETS 32
PROPERTIES(
"function_column.ttl_col"="v2",
"function_column.ttl"="3d"
);
Thank you for your feature proposal and for your willingness to submit a PR!
Could you please provide some specific real-world use cases for row-level TTL? It would be very helpful to understand the concrete business scenarios where this feature is required to better evaluate its necessity and design.
@morningman specific real-world use case:
Logistics fulfillment as we use Doris unique table to track down the states of specific orders. We may use multiple partial updates to update different parts of order information with different order states. The most instinctive filters for data recycle is by the time of the whole order is completed, but the complete time could only be updated after the whole order is finished and the actual fulfillment time of an order may vary in a relative long period. It's hard for us to do data lifecycle management with partitioned table in such cases.
We're closing this issue because it hasn't been updated in a while.
If you'd like to revive this issue, please reopen it and feel free a maintainer to remove the Stale tag!
Activity
morningman commentedon Mar 6, 2026
Thank you for your feature proposal and for your willingness to submit a PR!
Could you please provide some specific real-world use cases for row-level TTL? It would be very helpful to understand the concrete business scenarios where this feature is required to better evaluate its necessity and design.
TsukiokaKogane commentedon Mar 9, 2026
@morningman specific real-world use case:
Logistics fulfillment as we use Doris unique table to track down the states of specific orders. We may use multiple partial updates to update different parts of order information with different order states. The most instinctive filters for data recycle is by the time of the whole order is completed, but the complete time could only be updated after the whole order is finished and the actual fulfillment time of an order may vary in a relative long period. It's hard for us to do data lifecycle management with partitioned table in such cases.
morningman commentedon Mar 11, 2026
Thank you for the detailed explanation. We look forward to your PR!
github-actions commentedon Sep 7, 2026
We're closing this issue because it hasn't been updated in a while.
If you'd like to revive this issue, please reopen it and feel free a maintainer to remove the Stale tag!
[feature](storage) Support row-level TTL (#65858)