In embedded mode I definitely found that H2 was faster than Derby for reads on a single-threaded workload. However, embedded H2 only supports a single thread to run statements and does not support concurrent thread access. So when I added multiple threads on a multi-core box Derby scaled linearly while H2 remained the same. I am building a shared-nothing architecture where scalability and performance of the system gears mostly on sharing cache memory between threads on a multi-core box to reduce I/O hits and network serialization. So in my use case Derby wins hands down.
For other use cases we will most likely find various results. However, I have to say that the blanket statements made on the H2 site have lead to a misperception on the part of the user community that H2 is generically faster than Derby (at least among people I have met). It made it quite difficult for me to justify running our own independent benchmark to management when they were looking at the benchmark on the H2 site. It's actually kind of strange (and disappointing) to see this kind of one-upsmanship going on in the open source world. Maybe I'm naive but I thought blanket statements and whitewashing were the exclusive domain of commercial software! Cheers, Matt On 5/25/11 2:28 AM, "Bernt Marius Johnsen" <[email protected]> wrote: > Hi, > > There was some rounds on this with the H2 guy on this some years ago > too. Back then the claim on e.g. limit/offset where correct btw., so it > was basically the performance claim that was the topic. But they did not > seem to want to correct that claim. > > I also find the PolePosition "benchmark" a bit dubious. > > > On 05/25/2011 11:02 AM, Lukas Eder wrote: >> I have been following this thread curiously and raised the question on >> the H2 user group: >> >> http://groups.google.com/group/h2-database/browse_thread/thread/bc712e8607ab0 >> 73b >> >> 2011/5/25<[email protected]>: >>> >>> May be the Article used an older version of derby. T's a pity that they >>> don't say what version were used for comparison. >>> >>> >>> -----Ursprüngliche Nachricht----- >>> Von: Rick Hillegas [mailto:[email protected]] >>> Gesendet: Dienstag, 24. Mai 2011 20:12 >>> An: Derby Discussion >>> Betreff: Inaccuracies in H2's claims: Autocounter/Sequqnce-Numbers >>> >>> There seem to a number of mis-statements on this page: >>> >>> o The performance claim. >>> >>> o The claim that Derby doesn't have an "Explain plan" feature. >>> >>> o The claim that Derby doesn't support user-defined datatypes. >>> >>> o The claim that Derby doesn't support sequences. >>> >>> o The claim that Derby doesn't support limit/offset. >>> >>> o The claim that Derby doesn't support case-insensitive columns. >>> >>> On 5/24/11 10:02 AM, Tim Dudgeon wrote: >>>> It was not me who said Derby is slow. I'm using it in embedded mode >>>> all the time and performance is great. >>>> I was just pointing out that others are saying things that seem to be >>>> wrong, and some action might be wanted. >>>> >>>> Tim >>>> >>>> On 23/05/2011 17:00, Matt Pouttu-Clarke wrote: >>>>> Tim, >>>>> >>>>> Does H2 allow multiple concurrent threads to update the database? >>>>> I'm not >>>>> sure it's fair to compare a single threaded database to a multi-threaded >>>>> database with a single threaded workload. >>>>> >>>>> I have done benchmarks that show that Derby is much faster than H2 >>>>> with a >>>>> multi-threaded workload in embedded mode. >>>>> >>>>> Cheers, >>>>> Matt >>>>> >>>>> >>>>> On 5/21/11 3:56 AM, "Tim Dudgeon"<[email protected]> >>>>> wrote: >>>>> >>>>>> There are some other things here that might deserve some comment: >>>>>> http://www.h2database.com/html/features.html#comparison >>>>>> >>>>>> e.g. performance of embeded derby is slow! >>>>>> >>>>>> Tiim >>>>>> >>>>>> >>>>>> On 18/05/2011 16:05, >>>>>> [email protected] wrote: >>>>>>> Hi to all, >>>>>>> >>>>>>> in http://www.h2database.com/html/features.html#feature_list I found >>>>>>> this particular statement to above topic: >>>>>>> >>>>>>> *Sequence*and autoincrement columns, computed columns (can be used for >>>>>>> function based indexes) >>>>>>> >>>>>>> Later on is a matrix that shows some RDBMs in releation to some >>>>>>> features >>>>>>> where it is denied that Derby supports sequences. >>>>>>> >>>>>>> So what is actually the case? And if Derby supports running numbers >>>>>>> (in >>>>>>> Oracle they are called /sequences/, in Microsoft DBs the are often >>>>>>> called /auto counters/) how are they to be used. >>>>>>> >>>>>>> Thanks in advance for any hint >>>>>>> >>>>>>> Malte >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> iCrossing Privileged and Confidential Information >>>>> This email message is for the sole use of the intended recipient(s) >>>>> and may contain confidential and privileged information of iCrossing. >>>>> Any unauthorized review, use, disclosure or distribution is >>>>> prohibited. If you are not the intended recipient, please contact the >>>>> sender by reply email and destroy all copies of the original message. >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >
