How to Set Up Data Caching in Retool

Before enabling caching, identify which queries are slowest using the Debug Panel. Click the bug icon to open the Debug Panel. Switch to the Queries tab. Run your app and observe query execution times in the waterfall. Queries taking more than 300ms that run frequently are the best cache candidates. Sort the list by duration — the longest-running queries at the top of the list are your highest-impact cache opportunities.

For each slow query identified, ask: 'How often does this data change, and how stale is too stale?' Create a simple TTL selection guide: data that changes real-time (order status, inventory) → no cache. Data that changes hourly (daily aggregates, reports) → 5-15 minute TTL. Data that changes daily (monthly summaries, customer stats) → 1-hour TTL. Reference data (lookup tables, country lists) → 24-hour TTL. Match the TTL to the acceptable staleness window for your business use case.

Open the slow query identified in Step 1. Click the 'Advanced' tab in the query editor. Scroll to find 'Cache the results' toggle — enable it. In the 'Cache TTL (seconds)' field, enter the TTL you determined in Step 2. For a daily summary query, enter 300 (5 minutes). For a reference data query, enter 3600 (1 hour). Save the query. The cache takes effect on the next run — the first run after enabling caching will always execute against the database and populate the cache.

1-- Example query with caching enabled
2-- Query name: getProductCatalog
3-- Advanced tab: Cache the results = ON, TTL = 3600 (1 hour)
4
5SELECT
6  id,
7  name,
8  sku,
9  category,
10  unit_price,
11  is_active
12FROM products
13WHERE is_active = true
14ORDER BY category, name;
15-- This query rarely changes (product catalog updates are infrequent)
16-- 1-hour cache drastically reduces load without meaningful staleness

Run your app again. Open the Debug Panel → Queries tab. Find your cached query in the list. After the first run (which populates the cache), trigger the query again. Observe that the second execution is near-instant (< 10ms). In the query detail, you should see metadata indicating 'served from cache'. You can also check programmatically with {{ queryName.servedFromCache }} — it returns true when the result came from cache.

Identify all write queries (INSERT, UPDATE, DELETE) that affect the same data as your cached queries. For each write query, add cache invalidation to its success handler. The cleanest approach is a dedicated JS Query that runs all invalidations and refreshes after any write. Wire this query to the 'On success' event handler of each write query.

1// JS Query: invalidateDashboardCache
2// Triggered by write operation success events
3// Clears and refreshes all related cached queries
4
5await Promise.all([
6  getProductCatalog.invalidateCache(),
7  getDailySummary.invalidateCache(),
8  getCategoryStats.invalidateCache(),
9]);
10
11// Immediately re-populate cache with fresh data
12await Promise.all([
13  getProductCatalog.trigger(),
14  getDailySummary.trigger(),
15  getCategoryStats.trigger(),
16]);
17
18utils.showNotification({
19  title: 'Saved and refreshed',
20  notificationType: 'success',
21});

Review the Debug Panel Performance tab weekly to confirm caching is reducing query execution times. If a query's average execution time is consistently low after enabling caching, the cache is working. If it's still slow, check whether the cache key is changing too frequently (different parameter values creating many unique cache entries) or whether the TTL is set too short. Adjust TTL values based on observed usage patterns.