Hi Alex, Thanks for raising this.
I fully support the direction, removing TreeMapMetaStore makes sense (I'm not a big fan of the "transactional" naming as it's causing confusion imho). The two alternatives you propose for tests are indeed superior: they exercise real production code paths, which makes the test coverage more meaningful, not less. On the classes that may have been extended outside Polaris (LocalPolarisMetaStoreManagerFactory, TransactionalPersistence, AbstractTransactionalPersistence): I'd suggest a formal deprecation in one release before removal (with a note in the CHANGELOG), with a clear message pointing to the JDBC/NoSQL alternatives. That gives external adopters a heads-up without blocking the cleanup. On the default persistence question, H2+JDBC as an out-of-the-box default makes sense to me. It's Category A, it's already in the server image, and it's honest about what Polaris actually is. +1 on moving forward with a concrete proposal. Thanks! Regards JB On Fri, Jun 12, 2026 at 5:24 PM Alexandre Dutra <[email protected]> wrote: > Hi all, > > I am writing to ask the community whether it is OK to deprecate > TreeMapMetaStore, as well as all the in-memory metastore manager, > metastore manager factory, and persistence types that rely solely on > TreeMapMetaStore. > > As we know, these components are test-grade only, and not suitable for > production. They trigger a production readiness alert on Polaris > startup. It's a considerable amount of code that is virtually dead in > production. > > It's also confusing for developers. E.g. the "transactional" metastore > is not transactional in the JDBC sense of the term, and thus not used > by JDBC persistence. It also has its quirks: some return statuses are > only returned by that manager. > > However, these components are used in tests, and I agree that it's > useful to have an in-memory version of the persistence layer for > tests. But we have today two alternatives that are imho superior for > tests in polaris-runtime-service: > > - JDBC persistence with H2 backend. There are already a few tests > using this setup. > - NoSQL persistence with InMemory backend. > > Both alternatives test real production-grade persistence code. > > And finally, TreeMapMetaStore is currently the default runtime > persistence in application.properties; and the Helm chart also > advertises it as the default. These are not sane defaults, imho. It's > always tricky to provide a good default for datastores, but since JDBC > persistence is included by default in the server image, I think that > including the H2 driver by default could give us a saner default while > keeping the out-of-the-box experience intact (the license is Category > A). > > Concretely: > > On the MetaStoreManagerFactory hierarchy, the following > implementations are completely in-memory: > > - InMemoryPolarisMetaStoreManagerFactory: could be removed > > - InMemoryAtomicOperationMetaStoreManagerFactory: could be removed > > - LocalPolarisMetaStoreManagerFactory: is the base class of the two > above; imho it can be removed, but since it's an abstract class, it > may have been extended outside Polaris. But neither JDBC nor NoSQL use > it. > > On the PolarisMetaStoreManager hierarchy: > > - TransactionalMetaStoreManagerImpl: is only used by > LocalPolarisMetaStoreManagerFactory. JDBC and NoSQL do not use it. > Could be removed. > > - TransactionWorkspaceMetaStoreManager however is a different beast, > in spite of the similar name. It is in use today on the commit path, > so should not be removed. > > On the BasePersistence hierarchy: > > - TreeMapTransactionalPersistenceImpl and its TreeMapMetaStore are > only used by InMemoryPolarisMetaStoreManagerFactory, and could be > removed; > > - TransactionalPersistence and AbstractTransactionalPersistence: these > are supertypes of TreeMapTransactionalPersistenceImpl and thus only > used for in-memory. They imo can be removed, but they might have been > extended or implemented outside Polaris. > > I think it's important to keep Polaris code tidy by removing unused, > unimplementable, or test-grade only components. > > What are your thoughts? > > Thanks, > Alex >
