That's where I'm tending towards as well, QuestDB. I think it's a good idea to back whatever appropriate capabilities with the same database library if only just for maintenance purposes. Of course the downside is any vulnerabilities that may arise, such as we had to deal with re: H2 a couple years ago.
Regards, Matt On Fri, Sep 19, 2025 at 11:34 AM David Handermann < [email protected]> wrote: > Hi Peter, > > Another option I am evaluating is QuestDB [1]. There is an optional > framework extension that uses QuestDB for persistent Status History. I > would not intend to couple or reuse code from that module, but > building a new implementation of the Audit Store on QuestDB might be a > good solution. The Flow Configuration History is certainly > timestamp-oriented, so this might be a potential way forward. > > Regards, > David Handermann > > [1] https://questdb.com > > On Fri, Sep 19, 2025 at 9:36 AM Peter Gyori <[email protected]> wrote: > > > > Hi David, > > > > Thank you for your reply. > > > > Regarding NIFI-12468: whenever an Xodus transaction exceeds 60 seconds, > the > > database connection is terminated, and NiFi does not recover without a > > restart. (Interestingly, with NiFi-1.x using Java11, recovery is not an > > issue.) > > > > I also evaluated YouTrackDB, but ultimately decided against it. As an > > object-oriented graph database, YouTrackDB seems to be a more high-level > > and complex solution than the simple key-value datastore we are looking > for. > > > > Regards, > > Peter > > > > On Fri, Sep 19, 2025 at 3:19 PM David Handermann < > > [email protected]> wrote: > > > > > Hi Peter, > > > > > > Thanks for initiating this discussion. Despite activity on other > > > branches, I have also observed the lack of recent releases for Xodus. > > > I have not encountered the issues described in NIFI-12468, but I agree > > > that an alternative needs to be considered based on the lack of > > > maintenance activity. It is interesting that Xodus now mentions future > > > work on YouTrackDB, but that repository has not published a release to > > > Maven Central, so it does not appear to be in a helpful position. > > > > > > Anything that requires a native library and wrapper is not a great > > > candidate, like RocksDB as you noted. I looked at MapDB recently as > > > well, but I was also concerned about the maintenance level. I'm not > > > familiar with Chronicle-Map, so I plan to take a closer look. It > > > appears to have a number of dependencies, which is initially > > > concerning. Returning to H2 is not a good option, but mentioning it > > > for the sake of background. Apache Derby is another embedded database, > > > but it has had less maintenance in recent years. > > > > > > I plan to evaluate options and follow up, thanks again for raising the > > > topic! > > > > > > Regards, > > > David Handermann > > > > > > On Fri, Sep 19, 2025 at 7:46 AM Peter Gyori <[email protected]> wrote: > > > > > > > > Team, > > > > > > > > I am writing to propose we replace Xodus ( > > > > https://github.com/JetBrains/xodus ) in NiFi with a more actively > > > > maintained library. This change is necessary due to two key issues: > > > > > > > > - The Xodus project is no longer under active development. > > > > - We've encountered issues with Xodus when running NiFi on Java > 21, as > > > > detailed in the comments of > > > > https://issues.apache.org/jira/browse/NIFI-12468 > > > > > > > > I have evaluated some potential replacements and have summarized my > > > initial > > > > findings below. > > > > > > > > Replacement Candidates: > > > > > > > > - RocksDB https://github.com/facebook/rocksdb > > > > - Pros: Popular, actively maintained, and license-compatible. > > > > - Con: Written in C++ and relies on JNI. > > > > - MapDB https://github.com/jankotek/mapdb > > > > - Pros: Java-based and license-compatible. > > > > - Con: The last release was in January 2024. > > > > - Chronicle-Map https://github.com/OpenHFT/Chronicle-Map > > > > - Pros: Java-based, actively maintained, and > license-compatible. > > > > > > > > I welcome your input on this proposal, these candidates or any other > > > > alternatives you might suggest. > > > > > > > > Regards, > > > > Peter > > > >
