home User Guide Getting Started Help Center Documentation Community Training Certification
Looker keyboard_arrow_down
language keyboard_arrow_down
persist_for (for Explores)

This page refers to the persist_for parameter that is part of an Explore.

persist_for can also be used as part of a model, described on the persist_for (for models) parameter documentation page.

persist_for can also be used as part of a derived table, described on the persist_for (for derived tables) parameter documentation page.


explore: explore_name {
  persist_for: "1 hour"



Default Value

The persist_for setting of the model


A string containing an integer followed by a timeframe (seconds, minutes, or hours)

Special Rules

A persist_for setting at the explore level will override the persist_for setting at the model level


Consider instead using a datagroup and persist_with, as described on the Caching queries and rebuilding PDTs with datagroups documentation page.

persist_for enables you to modify the amount of time that cached query results are used for a given Explore. The default cache length in Looker is 1 hour. Cache results are stored in an encrypted file on your Looker instance.

The caching mechanism in Looker works as follows: Once a user runs a specific query, the result of that query is cached. If precisely the same query (everything must be the same, including things such as the row limits, etc.) is run again, in less than the time period specified by persist_for, the cached results are returned. Otherwise, a new query is run against your database.

When the persist_for time expires, data is deleted from the cache, as long as the Instant Dashboards Looker Labs feature is disabled. See the Caching queries and rebuilding PDTs with datagroups documentation page for information on how long data is stored in the cache.

If persist_for is set for both an Explore and its model, the value set for the Explore will take priority for queries based on that Explore.

Seeing whether a query was returned from cache

You can determine whether or not a query has been returned from the cache by looking in the upper right corner after running a query.

If results are from a fresh query,
you will see …
If the results are from the cache,
you will see …

Forcing new results to be generated from the database

Users can also force new results to be retrieved from the database. Select the Clear Cache & Refresh option from the gear menu, which you’ll find in the upper right of the screen after running a query (including merged results queries):

A persistent derived table normally is regenerated based on the specified datagroup, persist_for, or sql_trigger_value parameter. You can force the derived table to regenerate early if your admin has given you the develop permission, and you are viewing an Explore that includes fields from the PDT. Select the Rebuild Derived Tables & Run option from the gear drop-down menu, which you’ll find in the upper right of the screen after running a query:

See the Derived tables in Looker documentation page for further details about the Rebuild Derived Tables & Run option.


Adjust the cache length to 2 hours:

explore: my_explore { persist_for: "2 hours" }

Adjust the cache length to 30 minutes:

explore: my_explore { persist_for: "30 minutes" }

Turn off caching so that users never get cached results for a query:

explore: my_explore { persist_for: "0 seconds" }

Things to consider

When persist_for is set to 0 seconds, your users’ queries will not retrieve data from the cache. However, Looker requires the disk cache for internal processes, so your encrypted data will always be written to the cache, even when persist_for is set to 0 seconds. Once written to the cache, the data will be flagged for deletion but may live up to 10 minutes on disk. See the Caching queries and rebuilding PDTs with datagroups documentation page for details.

persist_for does not necessarily align with your data import

Many companies have a daily data import to their analytics database. Sometimes, they reason that there is no purpose running fresh queries if the data isn’t constantly updated anyway, so they set the cache length to 24 hours (like persist_for: 24 hours). However, this will not prevent users from getting data that is older than the most recent refresh.

For example, suppose a query is run at noon on January 1st, new data is imported the morning of January 2nd, and then the query is run again at noon on January 2nd. Since the query was run within the 24 hour window specified by persist_for, the data from January 1st will be returned, even though new data was loaded on January 2nd.

If you want your caching to be aligned with data imports, use a datagroup and persist_with, as described on this page about caching.

Scheduled Looks will cache results

When a scheduled Look is run, it will create a cached result set in the same way that a user run query would. If you want to pre-cache a certain report, you may want to consider saving and scheduling it.