So polyscale is an edge-based cache for your DB. I immediately scrolled to the "Cache Invalidation" section, since that's the hard bit.
TL;DR - They also have you route your writes through Polyscale, and they watch the data being written to decide what needs to be invalidated, then it sounds like there's a fallback for complex queries that just looks at last time a table was hit.
I wonder how things like views and prepared statements work?
Prepared statements work fine. Views can be tricky.
The statistical invalidation will in general disable caching on views since their results will change without any corresponding writes (because we only associate writes with the backing tables of the view). Currently our best answer to views is the new stale-while-revalidate flow which revalidates against the db while still serving a hit. With this feature enabled, one can turn off invalidation (if the resulting eventual consistency is acceptable).
3 comments
[ 2644 ms ] story [ 1083 ms ] threadTL;DR - They also have you route your writes through Polyscale, and they watch the data being written to decide what needs to be invalidated, then it sounds like there's a fallback for complex queries that just looks at last time a table was hit.
I wonder how things like views and prepared statements work?
Prepared statements work fine. Views can be tricky.
The statistical invalidation will in general disable caching on views since their results will change without any corresponding writes (because we only associate writes with the backing tables of the view). Currently our best answer to views is the new stale-while-revalidate flow which revalidates against the db while still serving a hit. With this feature enabled, one can turn off invalidation (if the resulting eventual consistency is acceptable).
More details about how invalidation works here:
https://www.polyscale.ai/blog/approaching-cache-invalidation...