We use derby in our search engine project which is in beta stage.
Having tried alternatives (mysql , postgre , oralce ) derby provieded us
unmatched performence over large datasets our current dataset is around 30GB
for each server we read more than a million rows at a time and insert around
300 records per second we are confident that
derby will not let us down along the way. we are planning to hit over 100GB mark for
both of our servers during the next couple of months.
if you wanna see how it performs check out our search engine(beta)* at http://www.blooby.com
I've been using Derby (it was once called Cloudscape) for years now in various projects. It has yet to let me down. No corruption, it's very robust, backups work fine. Performance has never been an issue, but I can't say I've really pushed Derby to its limits.
Our latest project uses Hibernate to integrate with Derby - no issues there. We also use SQuirreL SQL with Derby - that works nicely too.
The sign of a good embedded database system is not who’s running it, but rather who doesn’t know they’re running it! The ideal database is one that sits there in the background, working hard, and never raising a peep nor complaining. That’s Apache Derby!
We’ve been using Apache Derby as the default database for our print management application, PaperCut NG ( http://www.papercut.biz/ ), for 2 years now. Our software has been deployed by tens of thousands of organizations ranging from small schools all the way up to prestigious academic organizations and corporate banks. Although we offer the option to choose other external databases, the majority stick with Apache Derby as the embedded default. Many PaperCut NG installations handle thousands of print transactions a day and host datasets in the millions of rows. Apache Derby has proven that an embedded zero-administration database can be robust and scalable in a range of environments and operating systems.
At the technical level, PaperCut NG ships with Derby set up as a default meaning that users can use our system out-of-the-box without the need to undertake any DB setup tasks. We use Hibernate for OR mapping and Spring for transaction management. Apache Derby slotted into this environment without any problems.
We highly recommend Apache Derby (and so would our customers if they knew they were running it ;-).
Derby is an excellent embedded database when working with Java. I've worked on a project for over a year now that is using Derby in an embedded fashion. We use Derby embedded within a data profiling product. The purpose of the product is to help business users understand the nature of their data and also to audit data.
Derby is used as the container of data and the generated metrics. A Derby database is created for every execution and is populated by the engine that generates the metric results. The created database is queried when an end user clicks on a graph within a report. For example, if a user runs an equal range binning metric on a numeric field, the input data is binned into a fixed number of buckets. The population of each bucket is graphed and presented to the user. If the user clicks on a part of the graph (lets say bin 1), the Derby database is queried to find all rows that fall into that bin. The data is then displayed using a data browser.
The "drill down" feature of this product has been a very popular one with users and would have been much harder to create without Derby. The small footprint of Derby is amazing given the amount of functionality it provides. I highly recommend Derby for ease of use and true embed-ability.
I'm currently using derby for a distributed client architecture. I've tested with 3~5 million records that need to be keep in sync through all the clients. Derby has worked beautifully, selects, inserts all very fast. And I've even seen several searches with the same indexes run faster on Derby than Oracle. I eagerly await the continued development of Derby. I would like to see cursor statements similar to Oracle.
We've been using Apache Derby embedded into rich clients we've been delivering to various customers. It is undeniable that it strength reside in being able to power any Java application, being it rich client, web application or others completely hidden from the user / installer.
It has been deployed together with a JPA implementation, fully enabling object oriented programming principles to developers. We've used it to distribute the persistence of server side entities to rich clients, enabling users to work offline and then resynchronize with the server as soon as a connection is again available.
Apache Derby has never let us down, providing incredible performances, especially embedded! Weird behavior was encountered due to JPA implementations, not Derby itself. To me it is just the proof of maturity level it has gained over the years. A level that widely used, but also younger framework haven't yet reached!