Caching
Contents
Caching stores query results temporarily so repeated calls don't re-run the query. This is different from materialization, which pre-computes and stores results on a schedule.
How caching works
When you execute an endpoint:
- PostHog checks if there's a cached result that's still within the data freshness window
- If yes, it returns the cached result immediately
- If no, it runs the query and caches the result
Data freshness
Data freshness controls how long cached query results are considered fresh. Instead of configuring cache duration and materialization sync frequency separately, you set a single data freshness value and PostHog handles the rest.
For non-materialized endpoints, the data freshness value determines how long query results are cached. Once the freshness window expires, the next request re-runs the query.
For materialized endpoints, data freshness controls the materialization schedule (how often PostHog re-runs the query and updates stored results). See materialization for details.
Configuring data freshness
Set your data freshness in the Configuration tab under Data freshness. The available options are:
| Value | Duration |
|---|---|
| 900 | 15 minutes |
| 1,800 | 30 minutes |
| 3,600 | 1 hour |
| 21,600 | 6 hours |
| 43,200 | 12 hours |
| 86,400 | 1 day (default) |
| 604,800 | 7 days |
Shorter durations serve fresher data but consume more compute. Longer durations are faster but may serve stale results.
See endpoint execution for more detail on how this can affect your results.
Caching vs materialization
| Feature | Caching | Materialization |
|---|---|---|
| Storage | Temporary | Persistent (S3) |
| Refresh | On demand | Scheduled |
| Best for | Moderate traffic, real-time needs | High traffic, expensive queries |
Use caching when you need relatively fresh data. Use materialization when query speed matters more than freshness.