Storage Tiering - Mixpeek

Mixpeek demotes idle data to cheaper storage on a schedule. The platform declares the default windows per data class. A namespace can override them, and a collection can override its namespace. Any part you leave unset inherits from the level above.

The `tiering` field

Namespaces and collections take the same tiering object on create and on update (PATCH /v1/namespaces/{namespace_id}, PATCH /v1/collections/{collection_id}).

Field	Type	What it does
`enabled`	boolean	Turn tiering on or off here. Unset inherits from above.
`idle_days.cold`	integer, at least 1	Days without a use before the cold tier.
`idle_days.frozen`	integer, more than `cold`	Days without a use before the frozen tier.
`exempt`	string	Opt out, with the reason (for example a legal hold). An exempt namespace or collection is never demoted. An empty reason is refused.

Examples

Keep a collection hot for 90 days and frozen after a year:

curl -X PATCH https://api.mixpeek.com/v1/collections/$COLLECTION_ID \
  -H "Authorization: Bearer $API_KEY" \
  -H "X-Namespace: $NAMESPACE_ID" \
  -H "Content-Type: application/json" \
  -d '{"tiering": {"idle_days": {"cold": 90, "frozen": 365}}}'

client.collections.update(
    collection_id=COLLECTION_ID,
    tiering={"idle_days": {"cold": 90, "frozen": 365}},
)

await client.collections.update(COLLECTION_ID, {
  tiering: { idle_days: { cold: 90, frozen: 365 } },
});

Exempt a namespace under a legal hold:

curl -X PATCH https://api.mixpeek.com/v1/namespaces/$NAMESPACE_ID \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"tiering": {"exempt": "legal hold, matter 2026-014"}}'

The older collection field tiering_rules is retired. It is returned on reads so existing records still parse; a write that sets it is refused. Use tiering.

Collection Lifecycle for moving a whole collection between index tiers by hand
Storage Format for what each tier stores