Overprovisioned table retention

Overprovisioned table retention

The Overprovisioned table retention optimization highlights tables that are using excessive amounts of time travel and failsafe storage. This typically happens when tables are modified frequently and the table is configured to retain long periods of historical data. To remediate this, you can reduce the time travel configurations on frequently updated tables to avoid high costs.

ℹ️
Note: This optimization follows Slingshot’s role-based access patterns and only shows overprovisioned tables to users if the table’s database is part of the user’s business org. If you have not assigned databases to business orgs, non-admins will be unable to access data for this optimization. For more information on assigning objects to business orgs, you can view the Org Management documentation.

Frequency of update

Daily @ 06:30

Fields in result

  • Table
  • Schema
  • Database
  • Base storage (TB)
  • Time travel storage (TB)
  • Failsafe storage (TB)
  • Monthly Replication cost ($)

Why is this helpful?

Time travel stores backup copies of data for up to 90 days and can grow to be very large for tables updated frequently, and Failsafe can add an additional 7 days of backup data. If this data is not being restored frequently, users may be paying heavily for storage if they aren’t using it. By reducing time travel settings, users can reduce their data costs.

FAQs

  • What are we considering to be “overprovisioned”?
    • If Time Travel + Failsafe is more than [10x] a user’s base storage amount, we are flagging that table as overprovisioned.
    • Note: We have seen cases where Time Travel is > 500x the base storage of a table, resulting in tens of thousands of dollars of cost per month.
  • What is time travel?
    • Time travel allows access to historical data for a user-defined period (1-90 days), enabling queries on past states and recovery of deleted or modified data.
  • What is failsafe?
    • Failsafe is a non-configurable, 7-day period during which historical data is stored by Snowflake, ensuring data recoverability in the event of a catastrophic failure. This period begins immediately after the time travel retention period ends.