Hi Dmitri, Thanks for the pointer. *Now understand the split.*
At the PolarisMetaStoreManager / Resolver layer, my original observation holds: NoSqlMetaStoreManagerFactory.getOrCreateEntityCache() returns null, and NoSqlMetaStoreManager doesn't implement the change-tracking methods that InMemoryEntityCache needs. So Resolver bypasses the entity cache that JDBC and TreeMap backends use. However, as you noted, NoSQL has caching one level down. The per-realm Persistence is wrapped by PersistenceCacheDecorator → CachingPersistenceImpl backed by CaffeineCacheBackend (enabled by default via polaris.persistence.cache.enable). This cache intercepts fetches and reference lookups and invalidates on writes. A couple of questions before I follow up on #4874: Is the lower-level CacheBackend considered the intended caching strategy for NoSQL, or is there still interest in also supporting InMemoryEntityCache for consistency with the other backends? Are there any benchmarks or hit-rate numbers comparing the NoSQL persistence cache vs the JDBC/TreeMap entity cache? It would be useful to know how different the behavior is under load. If the current design is intentional and performs well, I'll update the issue with a summary and possibly send a small docs PR clarifying the NoSQL caching architecture. Cheers, Vignesh On Wed, 24 Jun 2026 at 04:30, Dmitri Bourlatchkov <[email protected]> wrote: > Hi Vignesh, > > NoSQL Persistence has caching at a different level [1]. Not every > Persistence SPI call hits the database. > > [1] > > https://github.com/apache/polaris/blob/c6d966d6a701e356284671d81d5ce1af94bf8e7e/persistence/nosql/persistence/api/src/main/java/org/apache/polaris/persistence/nosql/api/cache/CacheBackend.java#L35 > > Cheers, > Dmitri. > > On Tue, Jun 23, 2026 at 4:37 PM vignesh a <[email protected]> wrote: > > > Hi all, > > > > I opened GitHub issue #4874 < > https://github.com/apache/polaris/issues/4874 > > > > > after noticing something while reading through the metastore > > implementations, and I wanted to get some feedback before diving into a > PR. > > > > From what I can tell, the NoSQL backend currently doesn't use the entity > > cache at all. Since NoSqlMetaStoreManager doesn't implement change > > tracking, NoSqlMetaStoreManagerFactory ends up returning null instead of > > creating an InMemoryEntityCache. > > > > That means every Resolver operation - principal lookups, catalog > > resolution, privilege checks, location validation, and so on - goes > > directly to the backing store. By comparison, the JDBC and in-memory > > TreeMap implementations both benefit from the existing cache. > > > > The details are in issue #4874 > > <https://github.com/apache/polaris/issues/4874>, but I was curious about > > the intent here. > > > > A few questions: > > > > - > > > > Is this a known limitation, or is it something that simply hasn't been > > addressed yet? > > - > > > > Is the expected long-term solution to add change tracking support for > > NoSQL? > > - > > > > Has anyone considered a lighter-weight approach for NoSQL caching, or > > are there consistency concerns that make that undesirable? > > - > > > > More generally, should we expect similar performance characteristics > > across the supported metastore backends, or is this difference > > intentional? > > > > The NoSQL backend is a supported production backend, so the lack of > caching > > stood out to me as a potentially significant behavioral difference rather > > than just an implementation detail. > > > > I'd appreciate any context before I spend time exploring solutions. > > > > Thanks, > > > > Vignesh > > >
