Hi Alex, Thanks for bringing this discussion up! My understanding is that H2 is also superior to TreeMap - although I'm not really sure why TreeMap was used initially or why H2 didn't replace it at the start. If anyone has historical context, that would be super helpful.
It would be a bigger undertaking but if someone is willing to take on the migration of the test cases, I would be a +1 to this proposal unless there is some other context that's unknown right now. Best, Adnan Hemani On Fri, Jun 12, 2026 at 8:24 AM 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 >
