Caches
A cache remembers recent search answers. Search “air fryer” twice in the same minute and the second answer comes straight back from the saved copy.
- Every list has one, with nothing to set up or pay for.
- It is on by default and there is no switch to throw.
How caching works
- Search and suggestion answers are cached per list, one saved answer per exact request, for a few minutes — long enough to soak up a burst, short enough that fresh data shows up quickly.
- Best-effort by design: a slow or unreachable cache is skipped and the answer worked out fresh. A broken cache can never break your search.
- A search across a group is cached too — it borrows the cache of the lists in it.
The built-in cache
The reserved in-memory service (provider Search Stack on the Caches page) is the default and needs no setup: answers are kept in the memory of the server that handled the request. Capacity and region are managed for you and included in every plan, free included.
Bringing your own Redis
No longer offered. Search Stack used to let an account connect its own Redis, Valkey or Azure Managed Cache. A customer-run cache sits on the hot read path, and an unreachable one has already cost us an incident — while the query load it saves is ours, not yours.
- Caches already connected keep working and stay listed, and a list pointed at one keeps using it.
- No new ones can be added. Every other list is on the built-in cache.