Flux has used the HSQL in-memory database since Flux's launch in 2000. It's a nice and easy way to get programming with simple Flux examples in literally five minutes after downloading and installing Flux.

However, as I've talked about before, HSQL has its limitations.

The Derby database is now supported by the forthcoming Flux 8.0. It's a simple, embeddable, well supported database (Apache, Sun) that stores jobs and workflows persistently without using an enterprise class database such as Oracle, DB2, or MySQL.

From a Flux perspective, the only problem with Derby is that it doesn't support an in-memory mode, which can make things fast and simple. Fast, because an in-memory database doesn't hit the disk. Simple, because a fresh in-memory database is created each time a Flux engine is created.

Now enter H2. H2 is the popular successor to HSQL. It overcomes the glaring limitations in HSQL, supports an in-memory mode, and is still fast!

Yesterday I integrated H2 into Flux 8.0. It was easy.

I just ran a simple speed test of loading and firing a simple Java Action job. H2 took about 4.5 seconds. Derby took between 6.5 and 7.5 seconds.

All in all, H2 provides (a) simplicity over Derby since a fresh database is created whenever a Flux engine is created and (b) speed over Derby.

Of course, Derby is still very handy since it provides a robust persistence option. Since Derby is supported by both Apache and Sun, I have more confidence in it for data persistence than H2's persistence mode, which Flux won't be using.

H2 is now the default database in Flux 8.0. Derby is available as an option. Both H2 and Derby will ship embedded with Flux 8.0 so you'll never even have to include their jar files on your class path. Just include flux.jar.