Hi Damon, Okay, this makes your question bigger and harder to answer (to me at least) as lots of PHDs go into this topic. I won't make a recommendation but you should consider multiple factors in choosing your database. For example:
- Pure Java: I think most of the pure Java databases (Derby, H2, HSQL) are embedded into applications even though a server exists for Derby for example. This makes life easier for development and for shipping your application to end-users but connection pooling becomes a problem and you cannot access your database from outside your application while it is running. - Size: embedded databases are usually very small so you can deploy them on small devices. Apache Derby has a footprint of about 3 MB. - Setup: again embedded databases require zero setup. You just write code and go. - Tool support: Apache Derby does not have GUI tools for example whereas MySQL and Postgres have many powerful GUI and web DBA tools. - Load Balancing: If you use a client-server DB like MySQL or Postgres then you can load balance your application more efficiently and deploy your database over the network. - Features: I think the bigger systems like MySQL or Postgres support more advanced features like row level locking and all kinds of indexes (especially postgres) - Speed & Scale: Lots of studies out there Overall I usually choose Postgres out of concern for scale on enterprise systems. I know that postgres was deployed on massive production systems but cannot recall the same for Derby, H2 or HSQL and I don't want to make a bet on a production system. I could be wrong though and I'm not an expert in this area. I would love to hear the opinion of others. HTH & Cheers Taher Alkhateeb ----- Original Message ----- From: "damon henry" <[email protected]> To: [email protected] Sent: Friday, 10 July, 2015 2:51:19 AM Subject: RE: Using Derby in Production? Nothing to specific. I just realized that I had always been steered away from using Derby without any solid evidence or reasoning to back it up. So I thought I would ask the question. As far as specific problems, I have had a few, but they were not at a point that made them particularly worth troubleshooting. I do remember having some problems using MS SQL Server so I struck that off the list. I have been planning on using Postgres as I read that it is likely the most compatible and what OFBiz was developed on, but then one of the Dev instances I have been playing with suddenly developed problems writing records. Again I have not taken the time to troubleshoot, because I am still at a stage where it is easier just to spin up a whole new instance and get back to work :) I am starting to plan a production system, so I thought I would ask the question before committing to a standalone database. thanksDamon > Date: Fri, 10 Jul 2015 01:16:20 +0300 > From: [email protected] > To: [email protected] > Subject: Re: Using Derby in Production? > > Hi Damon and everyone, > > Is there a specific reason why you want Derby in production? Do you > specifically need the "embedded" part? And what is it that is problematic for > you with stand alone databases? Is it setup, administration, backup or what? > > I think we can help you better if we understand your exact problem so > answering the above would give us a clearer picture. > > Cheers! > > Taher Alkhateeb > > ----- Original Message ----- > > From: "Ron Wheeler" <[email protected]> > To: [email protected] > Sent: Friday, 10 July, 2015 12:04:08 AM > Subject: Re: Using Derby in Production? > > Derby is used in production. > > http://osdir.com/ml/derby-user-db-apache/2014-01/msg00053.html > http://www.carehart.org/resourcelists/derby_for_cfers/#notdevonly > http://wiki.apache.org/apachecon/Us2005OnlineSessionSlides?action=AttachFile&do=view&target=ApacheCon05usDerbyPerformance.pdf > > 10 year old comparison of Derby and MySQL > http://wiki.apache.org/db-derby/UsesOfDerby from the Derby wiki > > Testing under your forecasted production transaction load might give you > a better sense of which database system will give you adequate performance. > > Ron > > > On 09/07/2015 12:09 PM, Pierre Smits wrote: > > Damon, > > > > We advice against the use of Apache Derby as the underlying RDBMS for > > production environments. However, you can read up on how the developers of > > that product think about how to use it at http://db.apache.org/derby/ . > > > > Best regards, > > > > Pierre Smits > > > > *ORRTIZ.COM <http://www.orrtiz.com>* > > Services & Solutions for Cloud- > > Based Manufacturing, Professional > > Services and Retail & Trade > > http://www.orrtiz.com > > > > On Thu, Jul 9, 2015 at 5:47 PM, damon henry <[email protected]> wrote: > > > >> Is there any rule of thumb or general wisdom about using the Derby > >> database engine in a production deployment? In previous enterprise systems > >> I have integrated, I have often used Derby during development, but then > >> migrated to a standalone database system before putting things in > >> production. I am working on my first OFBiz implementation and assumed I > >> would be going that route on this project as well, so tried a few > >> different > >> standalone databases (mysql, postgres, MS SQL Server) with OFBiz, but to > >> be > >> honest I am not seeing any clear advantage, and have in fact run into a > >> few > >> issues with the stand alone databases. I also work for a much smaller > >> company now than I have in the past. This is not going to be a large > >> implementation, meaning it is not likely to host lots of simultaneous > >> connections, but once it gets put in place it may be in place for years > >> and > >> accumulate lots of data over the lifetime. Is Derby up to the task? Has > >> anyone used Derby over a long period of time and found it to perform well. > >> thanksDamon Henry > > > -- > Ron Wheeler > President > Artifact Software Inc > email: [email protected] > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > >
