Recently, I had cause to look at HSQLDB, one of several pure Java databases out there. At my job, we use RDBMS technology to back our deductive database systems. As such, we have need for a small-scale development RDBMS to accompany larger enterprise-grade RDBMS’s. For several years we have used H2, and it has been good to us. It is small, fast, very complete and reliable.
However, a couple years ago H2 changes it’s on-disk storage system. The new storage system is neater and cleaner, but it had a side effect: H2 is now significant less concurrent. Our deductive engine is highly concurrent (we implemented a form of Actor concurrency before we knew what Actors were), and we routinely run hundreds of SQL queries simultaneously. We treat the RDBMS backend much like a NoSQL database, and really thrash it at times, especially before the caching and materialization layers kick in. In recent years, as every machine gained cores like mad, this has become a problem. H2’s lack of concurrent execution sometimes slows the system down to the point where even on small datasets, Postgres is faster, despite the network hop. (This is not a knock on H2; highly concurrent access is not a design goal that seems to be emphasized. Fair enough.)
So this is a problem, so I decided it was time to survey embedded DB’s again. In the past, I had looked at HSQLDB and Derby and rejected them for performance reasons. Perhaps, in the intervening three years something had changed?