db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Segel" <mse...@segel.com>
Subject RE: Cloudscape Database Size limitation
Date Wed, 23 Nov 2005 14:49:06 GMT

-----Original Message-----
From: Dyre.Tjeldvoll@Sun.COM [mailto:Dyre.Tjeldvoll@Sun.COM] 
Sent: Wednesday, November 23, 2005 3:16 AM
Cc: derby-user@db.apache.org
Subject: Re: Cloudscape Database Size limitation

The following message is a courtesy copy of an article
that has been posted to comp.lang.java.databases as well.

aixunix@gmail.com writes:

> Does anyone know cloudscape database size limitation? Any documentation
> states the relation between cloudscape database size and performance?

For Derby (open source Cloudscape) I don't think there is a limitation
(other than those imposed by OS, jvm, available memory and disk). I
have seen it run with 10 GB, and I believe IBM is planning on testing
with up to 100 GB.

To get performance with a large database you may need to adjust the
pageCacheSize (the default is only 4MB).

The tests I have seen indicate that Derby performs better (relative to
other dbs) the larger the database is.

(I have cc'ed my reply to the derby-user mailing list, where more
derby experts are likely to see it. You can subscribe to and browse
this (and other) mailinglist at


I'm a little skeptical whenever I see a question like this.
There are always limits.

And while you could get up to 100 GB, I wouldn't recommend it performance
wise as Derby is currently written.

I think the important point isn't to find a theoretical limit, but to choose
the right database for the right job. 

1 GB is a lot of data.  Regardless of what database you are planning on
running. (Putting blobs aside for now.)

Derby still has some ugly warts. (Derby-47)as an example.
It has some limitations on how it stores data that will cause issues when it
starts to get large.

Going over a certain point, you're going to want to choose a database that
has a better storage method than using the file system.  
(And I had better clarify...)

I'm talking about having the data stored in either raw or cooked chunks. Not

As separate files within a directory. (More akin to Informix's Standard

The comment that Derby scales better to *other* databases, requires some
parameters. I wouldn't try to benchmark Derby against Informix or DB2.

Its more important in identifying the application requirements and then
seeing what database is going to meet your needs.

Note that there would have to be some changes to Derby if you were going to
offer the concept of a tablespace/chunk and then raw/cooked

But hey, what do I know?

Its not like I haven't been playing with databases since the 1980s?
(eeew! Now I know I'm getting old.) ;-)


View raw message