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(python), JRuby, 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. But that single process can be a server that allows other processes to connect as clients. When run in a client/server configuration, Derby has upgradable row-level locking, so high simultanious concurrency without much contention can be achived.
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.