That Little Issue of Durability
I think there is a lot more to choosing a database than performance. Yes, performance is important, and all other things being equal, it's a very good way to help you choose a database vendor.
What's problematic is that published performance numbers can often be misleading.
As an example, one place where Derby often gets compared is with other embedded databases, often showing where it's a big cumbersome oaf next to these screaming meemies. Take for example this comparison between H2 and some other databases out there. Derby in particular looks like a dog. Sigh...
But wait! Brian McAllister brings things back down to earth when he makes H2 and MySQL actually write to disk on transaction commit.
-- 1024 bytes, 1000 times --
derby: 2192 millis
bdb: 1849 millis
h2: 2221 millis
h2b: 2351 millis
-- 2048 bytes, 1000 times --
derby: 2199 millis
bdb: 2129 millis
h2: 2578 millis
h2b: 2414 millis
Hm, now Derby isn't looking so bad...
Now, I'm more than ready to say Derby has room for performance improvements, and I do know that the Derby team is working on this. But it's good to keep the story straight. You may not care about durability, in which case not writing to disk is a good choice to improve performance. But it's good to know what you're getting in to.
By the way, one of the folks I talked to at the Java DB pod during Java One wrote his own in-memory database, and is interested in adding support for an in-memory storage engine for Derby. In which case we could see some kick-ass numbers.
There is also the poor-man's way of running Derby in memory: set derby.system.home to /tmp or use the URL "jdbc:derby:/tmp/mydb".