Page History
- 2007-Oct-06 16:47 anonymous
- 2006-May-23 09:17 anonymous
- 2006-Mar-05 05:58 anonymous
- 2006-Feb-15 16:20 drh
- 2005-Sep-06 16:39 drh
- 2005-Jun-22 13:06 anonymous
- 2005-Apr-29 08:13 anonymous
- 2005-Apr-29 02:28 anonymous
- 2005-Apr-15 21:19 anonymous
- 2005-Apr-04 22:24 drh
- 2005-Apr-04 22:20 drh
- 2005-Apr-04 22:00 drh
- 2004-Dec-05 21:09 anonymous
- 2004-Nov-05 16:00 anonymous
- 2004-Aug-29 17:10 anonymous
- 2004-Aug-29 16:53 anonymous
- 2004-Aug-14 13:06 drh
- 2004-Aug-04 12:28 anonymous
- 2004-Aug-04 01:18 drh
http://www-306.ibm.com/software/data/cloudscape/ ,
and Derby at
http://incubator.apache.org/derby/index.html .
The information provided on this page was initially written based on a reading of the on-line documentation of Derby. Though the information is believed to be correct, the author is not a Derby expert and may have misunderstood parts of the documentation. If you find errors, you are encouraged to fix them.
Overall
Both SQLite and Derby operates directly from disk. Only parts of the database file(s) that are needed in order to carry out the requested operations are read.
Zero-Administration
Both SQLite and Derby offer zero-administration, embeddable SQL database engines. SQLite stores all the data in a single cross-platform disk file. Derby spreads its data across multiple disk files.
Host Language Support
SQLite is written in ANSI-C. It supports bindings to dozens of languages, including Java. Derby is written in Java and is thus usable only by Java and scripting languages that run on the Java VM (Jython, JRuby, Jacl, etc.)
SQL Language Support
Derby supports all of SQL92. SQLite only supports a subset of SQL92, though the supported subset is large and covers the most commonly used parts of SQL92.
Memory Utilization
The code footprint of SQLite is less than 250KB. The code footprint for Derby is about 2000KB compressed and is thus more than 8 times larger.
No information is available on the run-time memory utilization of Derby.
Concurrency
SQLite allows multiple simultaneous readers and a single writer. Mutiple processes can have the database open simultaneously.
Derby only allows a single process to have the database open at a time.
Derby allows increased concurrency in client/server mode. In client/server mode Derby supports giving multiple processes access to the database with row-level locking. But client/server mode requires that there be a thread or process available to act as the server. In standalone mode, Derby only allows a single process to connect to the database at a time.
Crash-Resistance
An SQLite database will survive a program crash or even a power failure. Same for Derby, as it provides transaction logging, recovery.
Database File Size
No data is currently available on the relative sizes of the database files for SQLite and Derby.
Speed
No data is currently available on the relative speed of SQLite and Derby database engines.
Their query operation is similar in function, relative speed of different queries depend on cache-utilization, query plan optimization and implementation.
However you should be prepared to unpredictable speed penalty when using Derby under different VMs ever on same hardware/OS.