Cache policy and invalidation

Cache policy defines which reads may be reused, how long a result remains useful, and what happens to related results after writes. These choices depend on application data semantics; the database remains the source of truth.

Observe before reusing results

Use transparent mode to inspect traffic without cache lookups or storage. Review query shapes, frequency, table relationships, write behavior, and freshness expectations. Use that evidence to identify reads that are both repeatable and safe to serve from cache.

Make behavior explicit

Reviewed scripts and hooks can prepare SQL, decide whether a read is eligible for caching, set its time-to-live (TTL), bypass cache reads or writes, and invalidate related results after a change. Keep rules focused and make volatile or sensitive reads bypass the cache.

For example, start with a frequently repeated read in transparent mode. Check its execution rate, backend latency, source tables, related writes, and freshness requirements. If reuse is appropriate, review a rule that gives the read a bounded TTL and invalidates its cached results when relevant writes succeed. Validate representative reads and writes, then compare hits, misses, latency, and invalidations after enabling the rule. The rule is a workload decision, not a promise that every read should be cached.

Invalidate conservatively

Writes and schema changes reach the backend. CacheDB can use query metadata and policy to remove related cached results after a successful change. When the relationship between a write and cached reads is uncertain, invalidate a wider scope rather than relying on incomplete metadata.

Cache reuse can be eventually consistent: a concurrent read may briefly observe an earlier result while invalidation is being applied. Keep strict read-after-write paths outside cache reuse unless the application can tolerate that behavior.

The optional AI Assistant can help investigate policy opportunities; operators review and validate every candidate.