LLMs.txt directory

Data Cache

Data Cache copies frequently queried data from your cloud data warehouse (CDW) into ThoughtSpot-managed storage, so eligible queries are served from the cache instead of running on your warehouse. This means faster answers and lower warehouse compute costs. ThoughtSpot routes a query to the cache when the cache can answer it, and runs it on your live warehouse when it cannot. Users always get a complete result either way. Once Data Cache is enabled for your cluster, data model editors can turn on caching for individual Models from the Caching tab in the Model editor. No changes to your Liveboards, Answers, SQL, or TML are required

To enable it for your cluster, contact ThoughtSpot support.

How it works

When you enable caching on a Model, ThoughtSpot copies the Model’s table data into ThoughtSpot-managed storage on a schedule you choose. Each eligible query is then evaluated at query time:

  • If the cache can answer the query, for example its date filters fall within the cached window, and the cache is healthy, ThoughtSpot serves the result from the cache, typically with sub-second latency.

  • If the query reaches outside the cached window, uses a construct the cache does not support, or the cache is unavailable, ThoughtSpot runs the query on your live warehouse.

Routing is automatic. Users do not choose between the cache and the warehouse, and the result is complete in both cases. The Caching tab shows the current state of the cache, and View history shows when each refresh ran.

Prerequisites

Before you can enable caching on a Model, the following must be true:

  • Data Cache is enabled for your cluster. Contact ThoughtSpot support to enable it.

  • The Model is built on a Snowflake or Databricks connection. More sources are being progressively added.

  • The connection uses a service account (non-OAuth, non-parameterized).

  • The Model does not use a custom calendar.

  • You have edit access to the Model. Users without edit access can open the Caching tab and view the cache settings, but cannot change them.

Enable caching on a Model

  1. Open the Model editor from the Data workspace.

  2. Select the Caching tab.

    If the Model is not cached yet, the tab describes the benefits of caching and shows Cache model. If Data Cache is not yet enabled for your cluster, Cache model is disabled and the tab asks you to contact ThoughtSpot support.

  3. Click Cache model

    The Caching Settings dialog opens.

  4. Under Tables to cache, choose how to cache each table in the Model:

    • Full copy (All history) — ThoughtSpot copies the entire table into the cache. Use this for dimension tables or tables where you need the full history available.

    • Date window (Time window) — ThoughtSpot copies a rolling window of rows, filtered by a date column you select. The default window is 13 months. You can adjust the window to any of the following: 1 month, 3 months, 6 months, 13 months, or a custom duration.

      A Model may mix full-copy and date-windowed tables. For example, you can cache a large fact table with a 13-month window and full-copy smaller dimension tables.

  5. Under Refresh schedule, choose how often ThoughtSpot refreshes the cache:

    • Frequency: Hourly, Daily, Weekly, or Monthly.

    • Time and timezone: Set the time the refresh runs.

      You can also trigger a manual refresh at any time.

  6. Click Save.

    The Caching tab switches to the cache settings view and shows the Configuring state while ThoughtSpot sets up the cache and loads the data for the first time.

Cache states

The Caching tab shows the current state of the cache for the Model.

State Meaning

Configuring

ThoughtSpot is setting up the cache for this Model. Queries run on your warehouse.

Caching

First data load is running. Queries run on your warehouse.

Active

Cache is loaded and serving queries.

Refreshing

A scheduled or manual refresh is running. The cache continues to serve queries from the most recent successful load.

Failed

The most recent refresh failed. Queries run on your warehouse. Open View history to see the failed refresh and its per-table detail.

Purged

Cached data has been deleted. Queries run on your warehouse. The caching configuration is kept, so you can cache the Model again without re-configuring.

Editing a cached Model

To keep the cache in sync with the Model, you must first turn off caching before renaming a column or adding a parameter.

  1. Open the Caching tab in the Model editor.

  2. Turn caching off.

  3. Make your desired changes.

  4. Turn caching back on and let the reload finish.

Turning caching off clears the cached data and run history, so plan your columns and parameters before you enable caching. Changing a parameter’s default value works without this step.

Refresh the cache manually

  1. Open the Caching tab in the Model editor.

  2. Click Refresh now.

ThoughtSpot starts a new load immediately. The previous cache continues to serve queries while the refresh runs. A manual refresh reloads all cached tables in full.

View refresh history

  1. Open the Caching tab in the Model editor.

  2. Click View history.

The run history shows each refresh: its type (scheduled or manual), start and end time, number of rows loaded, and whether it succeeded or failed. Click a row to see per-table detail.

Purge cached data

Purging deletes all data from the cache immediately. ThoughtSpot returns to serving all queries from your live warehouse. The caching configuration is preserved — you can re-enable without re-configuring.

  1. Open the Caching tab in the Model editor.

  2. Click Purge data.

  3. Confirm the action.

Disable caching

Disabling caching deletes all cached data and removes the caching configuration from the Model. This action cannot be undone.

  1. Open the Caching tab in the Model editor.

  2. Click Disable caching.

  3. Confirm the action.

Security

Data Cache preserves all existing ThoughtSpot security controls:

  • Row-level security (RLS) — RLS rules are applied to cached results exactly as they are to live warehouse results.

  • Column-level security (CLS) — CLS rules are applied to cached results in the same way.

  • Org isolation — Each Org’s cache is stored in a separate, isolated database. No cached data or credentials are shared across Orgs.

  • Encryption — Cached data is encrypted at rest. Credentials for accessing the cache are encrypted and stored per Org.

  • Opt-in — Caching is a double opt-in: your cluster administrator must enable Data Cache for the cluster, and a data model editor must enable it for each individual Model.When you enable caching on a Model, ThoughtSpot reminds you that the Model’s data is copied out of your CDW into ThoughtSpot-managed storage.

What is not supported

Some query types cannot be served from the cache. ThoughtSpot runs these on your warehouse automatically, and the result is the same either way. The following connections and Model configurations cannot be cached, or are always run on your warehouse:

Not supported Detail

Non-certified connections

Data Cache supports Snowflake and Databricks only in this release.

OAuth or parameterized connections

Service-account connections only.

Custom calendars

Models using custom calendars cannot be cached.

RLS referencing other tables

Models whose RLS rules reference columns from other tables cannot be cached.

On-premise clusters

Data Cache is available on SaaS clusters only.

Data Cache and aggregate-aware Models

If a Model has both an aggregate-aware configuration and Data Cache enabled, ThoughtSpot checks the cache first. Queries the cache cannot serve run on your warehouse, where aggregate-aware routing applies as usual. You can use both together: caching reduces the load on your warehouse, and aggregate awareness speeds up the queries that still run there.

Data that works best with caching

For the most consistent results between cached and live answers:

Where What to note Tip

Case-insensitive text columns (Snowflake COLLATE ‘en-ci’)

Cached answers treat text as case-sensitive, so ‘abc’ and ‘ABC’ show as separate values

Store values in one case at the source, or keep these models live

Decimal values

Values that differ only after the 15th significant digit are stored as one value

Round at the source if you need finer precision

VARIANT / ARRAY columns

Stored as compact JSON, so text filters and grouping on the raw column can differ from live

Extract the fields you need as typed columns

Log of zero

ln(0), log2(0) and log10(0) return 0

Use if([Value] = 0, null, ln([Value])) for the same result cached and live

Infinity in DOUBLE columns

Answers that read these rows return an error

Replace with NULL or a large number at the source

Dates in year 0001

The yearly bucket shows as null; the raw date is fine

Group by the raw date

Formulas

edit_distance() isn’t supported on cached models yet. Use a live model for answers that need it.

Limitations

  • Tables cached as a full copy are copied in their entirety, so a practical size ceiling applies per Org. Contact your ThoughtSpot representative if you are approaching storage limits.

  • Changes to the Model, such as new or unhidden columns, are reflected in the cache at the next refresh, scheduled or manual.

  • Cache data is not included in cluster snapshots. After a cluster restore, caching must be re-established manually.