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.
Fundamental Differences
Previously it said here that Derby reads the entire database into memory and parses it into various Java data structures, that is wrong. It works very much like a traditional database.
So, I'm not sure what this part really should contain.
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 files, wheras Derby uses several files.
Host Language Support
SQLite is written in ANSI-C. It supports bindings to dozens of language, including Java. Derby is written in Java, provides JDBC access, local access (embedded) or remote access (tcpip), using JDBC, DRDA or ODBC drivers.
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 or about 8 time larger.
Concurrency
SQLite allows multiple simultaneous readers and a single writer. Mutiple processes can have the database open simultaneously.
Derby can operate in two modes, either as simply embedded when it is available only to once process through direct JDBC connection, or that single process can act as a server taking connections from several clients. 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.