Skip to content

[Feature] Row-level TTL #61056

Closed
Closed

Description

@TsukiokaKogane

Search before asking

  • 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.
Image

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:

CREATE TABLE example_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"
 );

Related issues

No response

Are you willing to submit PR?

  • Yes I am willing to submit a PR!

Code of Conduct

Activity

  1. morningman commented on Mar 6, 2026

    @morningman
    Contributor

    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.

  2. TsukiokaKogane commented on Mar 9, 2026

    @TsukiokaKogane
    ContributorAuthor

    @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.

  3. morningman commented on Mar 11, 2026

    @morningman
    Contributor

    Thank you for the detailed explanation. We look forward to your PR!

  4. github-actions commented on Sep 7, 2026

    @github-actions
    Contributor

    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!

  5. added a commit that references this issue on Oct 29, 2026
    cbe1308
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Stalekind/featureCategorizes issue or PR as related to a new feature.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions