Derby vs. PostgreSQL

[Marek Lewczuk]

Hello,
I'm using PostgreSQL (and I'm very happy with that), however I'm looking
for Java-based DBMS and Derby is a proper solution. I'm just curious how
Derby looks comparing to PostgreSQL - performance, features, license
etc. Does anyone have made such a comparisons ?

Thanks in advance.

ML

[simonz]

Hi Marek,

I have quite a lot of experience with PostgreSQL and am now working
for a company that is building a product that will include an embedded
Derby database.

Good - For a pure java embedded database I am most impressed with
derby - it is fantastic to be able to distribute a pure java solution
(tomcat etc.) - less moving parts, less dependencies, cross platform -
good.  We used HSQL to begin with and Derby blows it away for
performance.

Good - The list here is really helpful and friendly - I can only see
good things in the future.  (Same should be said for postgres, I would
add).

I do have some grumbles:

Bad - I find the docs confusing esp. with the amount of overlap b/w
"cloudscape" and "derby".  A lot of useful links/google searches dead
end into IBM land and that really frustrates me.  I assume though that
this will improve.  Postgres documentation by comparison is gorgeous.

Bad - I also find the bundled client tools really unfriendly for derby
compared to postgres - ij is horrible compared to psql.  Of course,
once you are using JDBC
you can use a whole bunch of different tools, but generally it seems a
lot of simple usability is lacking (eg. you have to set a special
parameter on the connection just to an error message back instead of a
cryptic code that you will struggle to find in documentation).

Bad - One thing that concerned me greatly was the ambiguity around
whether the driver was going to be released - yes, amazing, but true -
originally the whole DB was redistributable as open source but not the
driver to access it!  Well, I think this has been fixed for the java
access, but as far as I know if you want ODBC you are still NOT able
to redistribute the driver.   I would love to hear if this is going to
change.

I hope nobody working on derby takes these comments as a negative - if
they are wrong I apologize, please correct me.  I just wanted to give
the experience of a new user starting up with derby and the first
impressions.  Hope it's useful to you Marek!

Simon.

On 5/7/05, Marek Lewczuk <[hidden email]> wrote:

> Hello,
> I'm using PostgreSQL (and I'm very happy with that), however I'm looking
> for Java-based DBMS and Derby is a proper solution. I'm just curious how
> Derby looks comparing to PostgreSQL - performance, features, license
> etc. Does anyone have made such a comparisons ?
>
> Thanks in advance.
>
> ML
>
>

[Daniel John Debrunner]

Simon wrote:

> Bad - One thing that concerned me greatly was the ambiguity around
> whether the driver was going to be released - yes, amazing, but true -
> originally the whole DB was redistributable as open source but not the
> driver to access it!  

To be fair the main (embedded) JDBC driver to access it was released
under open source. I was surprised how many folks immediately used the
networked JDBC driver, rather than the embedded mode. But then it was
always a mind shift for folks to understand the embedded JDBC driver was
the complete database engine. Client/Server is more naturally understood
as it is more typical.

> Well, I think this has been fixed for the java
> access, but as far as I know if you want ODBC you are still NOT able
> to redistribute the driver.   I would love to hear if this is going to
> change.

Do I hear a volunteer for an open source ODBC driver for Derby?

Dan.

[Lance J. Andersen]

Daniel John Debrunner wrote:

Simon wrote:

  

Bad - One thing that concerned me greatly was the ambiguity around
whether the driver was going to be released - yes, amazing, but true -
originally the whole DB was redistributable as open source but not the
driver to access it!  
    

To be fair the main (embedded) JDBC driver to access it was released
under open source. I was surprised how many folks immediately used the
networked JDBC driver, rather than the embedded mode. But then it was
always a mind shift for folks to understand the embedded JDBC driver was
the complete database engine. Client/Server is more naturally understood
as it is more typical.
  

The reason that some of us always use the network JDBC driver is due to the environment we have to run in.  For example, in a J2EE world,  I need to be able to have my application client be able to access the same database
as my web or ejb apps.  This would not be possible for the majority of J2EE app servers without a redesign of  at least their application client container.

The other issue is that there are a couple of  problems with the embedded driver that we need to address (shreyas is working on these) that we did not encounter with the network driver.

In many cases, using the embedded driver is the way to go though.

Well, I think this has been fixed for the java
access, but as far as I know if you want ODBC you are still NOT able
to redistribute the driver.   I would love to hear if this is going to
change.
    

Do I hear a volunteer for an open source ODBC driver for Derby?

Dan.

  

[mikem_app]

There are many network, web and ejb apps that can use the embedded
driver, if it is possible to localize the database access logic in
the application server where the database is running.

Also remember that it may be better to use both the embedded driver
for the part of the application that can be local to the database,
while at the same time providing network driver access to parts of
the application that are database client/server model.  Often people
don't realize that both drivers can be used at the same time.  The
embedded driver operations don't have to pay network transmission
cost, so should perform equal or better to network driver operations
(the key factor is the amount of data flowing in either direction).

A typical application that uses this model is one that can embed
all application logic in an application or web server, and thus uses
the embedded driver.  But it wants to do network data gathering
every once in awhile, so uses the network driver to do that.

Lance J. Andersen wrote:

>
>
> Daniel John Debrunner wrote:
>
>>Simon wrote:
>>
>>  
>>
>>>Bad - One thing that concerned me greatly was the ambiguity around
>>>whether the driver was going to be released - yes, amazing, but true -
>>>originally the whole DB was redistributable as open source but not the
>>>driver to access it!  
>>>    
>>>
>>
>>To be fair the main (embedded) JDBC driver to access it was released
>>under open source. I was surprised how many folks immediately used the
>>networked JDBC driver, rather than the embedded mode. But then it was
>>always a mind shift for folks to understand the embedded JDBC driver was
>>the complete database engine. Client/Server is more naturally understood
>>as it is more typical.
>>  
>>
> The reason that some of us always use the network JDBC driver is due to
> the environment we have to run in.  For example, in a J2EE world,  I
> need to be able to have my application client be able to access the same
> database
> as my web or ejb apps.  This would not be possible for the majority of
> J2EE app servers without a redesign of  at least their application
> client container.
>
> The other issue is that there are a couple of  problems with the
> embedded driver that we need to address (shreyas is working on these)
> that we did not encounter with the network driver.
>
> In many cases, using the embedded driver is the way to go though.
>
>
>>  
>>
>>>Well, I think this has been fixed for the java
>>>access, but as far as I know if you want ODBC you are still NOT able
>>>to redistribute the driver.   I would love to hear if this is going to
>>>change.
>>>    
>>>
>>
>>Do I hear a volunteer for an open source ODBC driver for Derby?
>>
>>Dan.
>>
>>  
>>

[Lance J. Andersen]

Mike Matrigali wrote:

> There are many network, web and ejb apps that can use the embedded
> driver, if it is possible to localize the database access logic in
> the application server where the database is running.

agree

>
> Also remember that it may be better to use both the embedded driver
> for the part of the application that can be local to the database,
> while at the same time providing network driver access to parts of
> the application that are database client/server model.  Often people
> don't realize that both drivers can be used at the same time.  The
> embedded driver operations don't have to pay network transmission
> cost, so should perform equal or better to network driver operations
> (the key factor is the amount of data flowing in either direction).
>

I understand .  My point was that if I need to have an application
utilize  an application client to access DatabaseA and also have web/ejb
apps access DatabaseA, I need to use the network driver as  today with
the current implementation of most application clients.  Similar
scenario is true for clustered scenarios.

I am not saying you cannot use the embedded driver, just there are some
legit reasons why it does not meet everyone's needs.

> A typical application that uses this model is one that can embed
> all application logic in an application or web server, and thus uses
> the embedded driver.  But it wants to do network data gathering
> every once in awhile, so uses the network driver to do that.
>
> Lance J. Andersen wrote:
>
>>
>>
>> Daniel John Debrunner wrote:
>>
>>> Simon wrote:
>>>
>>>  
>>>
>>>> Bad - One thing that concerned me greatly was the ambiguity around
>>>> whether the driver was going to be released - yes, amazing, but true -
>>>> originally the whole DB was redistributable as open source but not the
>>>> driver to access it!    
>>>
>>>
>>> To be fair the main (embedded) JDBC driver to access it was released
>>> under open source. I was surprised how many folks immediately used the
>>> networked JDBC driver, rather than the embedded mode. But then it was
>>> always a mind shift for folks to understand the embedded JDBC driver
>>> was
>>> the complete database engine. Client/Server is more naturally
>>> understood
>>> as it is more typical.
>>>  
>>>
>> The reason that some of us always use the network JDBC driver is due
>> to the environment we have to run in.  For example, in a J2EE world,  
>> I need to be able to have my application client be able to access the
>> same database
>> as my web or ejb apps.  This would not be possible for the majority
>> of J2EE app servers without a redesign of  at least their application
>> client container.
>>
>> The other issue is that there are a couple of  problems with the
>> embedded driver that we need to address (shreyas is working on these)
>> that we did not encounter with the network driver.
>>
>> In many cases, using the embedded driver is the way to go though.
>>
>>
>>>  
>>>
>>>> Well, I think this has been fixed for the java
>>>> access, but as far as I know if you want ODBC you are still NOT able
>>>> to redistribute the driver.   I would love to hear if this is going to
>>>> change.
>>>>  
>>>
>>>
>>> Do I hear a volunteer for an open source ODBC driver for Derby?
>>>
>>> Dan.
>>>
>>>  
>>>
>