Time Travel
Time Travel allows you to query your database as it existed at any point in the past. This powerful feature enables data recovery, historical analysis, and debugging by accessing previous states of your data.
How Time Travel Works
Time Travel uses the FOR SYSTEM_TIME AS OF
syntax to specify a point in time for your query. Instead of seeing current data, you'll see exactly what the database looked like at that moment.
Key Capabilities
- Data Recovery - Restore accidentally deleted or modified data
- Historical Analysis - Track changes and trends over time
- Debugging - Identify when and how data issues occurred
- Conflict Resolution - Avoid transaction conflicts in high-concurrency scenarios
Time Range Limitations
Time Travel queries can access data from up to 23 hours ago by default. For longer historical access, use backup and restore functionality.
Common Use Cases
1. Recover Accidentally Deleted Data
Quickly restore data that was mistakenly deleted:
2. Debug Data Issues
Track down when and how data problems occurred:
3. Historical Analysis
Analyze trends and changes over time:
4. Avoid Transaction Conflicts
Read consistent data during high-concurrency operations:
Time Specification Formats
Tacnode supports multiple ways to specify time points:
1. Relative Time (Recommended)
Use relative time strings for convenience:
2. Exact Timestamps
Use specific timestamps for precise control:
3. Mixed Time Points in Joins
Set different time points for each table:
Advanced Examples
Transaction-Level Time Travel
Materialized View Time Travel
Complex Historical Analysis
Configuration and Optimization
Adjusting Retention Period
Control how long historical data is kept with the gc_ttl_seconds
parameter:
Configuration Guidelines:
- Minimum: 1800 seconds (30 minutes)
- Default: 82800 seconds (23 hours)
- Maximum Recommended: 604800 seconds (1 week)
- Performance Impact: Longer retention reduces query performance
Performance Considerations
- Shorter retention = Better performance - Balance historical access needs with query speed
- Index optimization - Ensure proper indexes exist for time-travel queries
- Storage overhead - Historical versions consume additional storage space
- Cleanup frequency - More frequent cleanup improves performance but uses more CPU
Best Practices
- Use relative time formats when possible (
'-1h'
vs exact timestamps) - Set appropriate
gc_ttl_seconds
based on your recovery needs - Monitor storage usage with longer retention periods
- Test time-travel queries on non-production data first
- Document your data recovery procedures using time travel