Set data retention

Use a table-level retention policy to make stored data eligible for asynchronous expiration after a configured window. ScopeDB accepts a whole number from 1 through 1825 days. Tables have no automatic retention policy unless you configure one.

Retention is a table lifecycle policy, not a row-level time-to-live rule. It does not use a timestamp column from your data to decide when an individual row expires. Because enforcement is asynchronous, eligible data may remain queryable for some time.

Check or set retention in Console or Catalog

In Console, open Data, select a table, and open Manage to check its current Retention setting. Select Edit table (or set Retention during Create table) to configure a retention window in days or choose Never expire, then select Review changes.

In the Catalog API or scope catalog, retention_days controls the policy on the table definition:

{
  "name": "events",
  "columns": [
    { "name": "time", "data_type": "timestamp" },
    { "name": "service", "data_type": "string" },
    { "name": "name", "data_type": "string" },
    { "name": "message", "data_type": "string" },
    { "name": "var", "data_type": "object" }
  ],
  "retention_days": 30
}

• Set "retention_days" to an integer from 1 through 1825 when creating or updating a table.
• Shortening an existing table's retention_days (or adding a retention limit where none was set) is a potentially destructive change because existing data can become eligible for removal. Preview the change with dry_run=true (or scope catalog plan) and pass allow_destructive=true (--allow-destructive in the CLI) when applying it.
• Set "retention_days": null (or omit retention_days) to remove the automatic retention policy. Removing or increasing the policy does not restore data that ScopeDB has already expired.
• Inspect a table's current retention setting from the terminal with scope catalog get --table scopedb.public.events; retention_days is null when the table has no automatic retention policy.

Choose a retention window

Use a window that matches how long the table remains useful and any retention requirements that apply to the data. If datasets need different windows, keep them in separate tables so each table can have its own policy.