> ## Documentation Index
> Fetch the complete documentation index at: https://docs.risingwave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Time travel queries

> This guide describes how to leverage the time travel feature. This feature helps access historical data at a specific time.

<Tip>
  **PREMIUM FEATURE**

  This is a premium feature. For a comprehensive overview of all premium features and their usage, please see [RisingWave premium features](/get-started/premium-features).
</Tip>

## Prerequisites

Time travel requires the meta store type to be [SQL-compatible](/deploy/risingwave-docker-compose#customize-meta-store). We recommend reserving at least 50 GB of disk space for the meta store.

The system parameter `time_travel_retention_ms` controls time travel functionality. By default, it's set to `600000`, i.e. 10 minutes. To modify retention period, you need to [alter this system parameter](/operate/view-configure-system-parameters#how-to-configure-system-parameters) to a non-zero value.

For example, you can set `time_travel_retention_ms` to `86400000` (1 day). Then historical data older than this period will be deleted and no longer accessible.

<Note>
  Increasing time travel retention period will introduce additional overhead to both the meta store and the object store.
</Note>

## Syntax

Specify `FOR SYSTEM_TIME AS OF` separately for each table accessing historical data. The following subclauses can be used:

* Unix timestamp in seconds. For example, `SELECT * FROM t_foo FOR SYSTEM_TIME AS OF 1721024455;`.
* Datetime. For example, `SELECT * FROM t_foo FOR SYSTEM_TIME AS OF '2000-02-29T12:13:14-08:30';`.
* NOW() \[ - Interval ]. For example, `SELECT * FROM t_foo FOR SYSTEM_TIME AS OF NOW() - '10' SECOND;`.

<Note>
  If you specify a point in time that is outside the time travel period, the query will return an error, like `time travel: version not found for epoch`.
</Note>

## Storage space reclamation

Stale time travel data in both the meta and object stores is automatically removed in the background, freeing up storage space.

Background vacuum preserves versions that are still within the `time_travel_retention_ms` window, including during snapshot backfill, so time travel queries remain available throughout the configured retention period.