Derby is a lightweight relational database implemented completely in Java. Using the JDBC driver provided, Derby can be embedded in any Java applications.


In 1997, Cloudscape Inc., a start-up in Oakland, California, developed a database engine called JBMS, which was later renamed as Cloudscape. From 1999 to 2001, Cloudscape was acquired first by Informix Software, and by IBM, and its name was changed to IBM Cloudscape. In 2004, IBM contributed the code to the Apache Software Foundation as Derby. In 2005, Derby became a Apache DB subproject.


Non-Blocking Fuzzy

Derby implements ARIES with slight variance. It allows fuzzy checkpointing. However, unlike ARIES implementation, it does not store a dirty page list in checkpoint records. Instead, during checkpoint, Derby flushes all database pages to disk. The checkpoint control files contains "undoLWM" and "RedoLWM". "UndoLWM" is set as the the starting LSN of the oldest active transaction when checkpoint starts, and "RedoLWM" is the the current LSN of the checkpoint.

Query Compilation

Code Generation JIT Compilation

Derby parses the prepared statement using Javacc and generates the Java binary code directly. JIT complier is supported, so that after several executions, JIT compiler will compile it to native code for performance improvement.

Stored Procedures


Derby support Java stored procedures.


Physiological Logging

Derby implements a combination of physical and logical logging. For actions on the same page, it uses physical logging. For BTree operations, which might affect several pages, it uses physical redo and logical undo.



Derby implements standard B+ Tree algorithms. It stores keys in leaf pages only. The B+ Tree supports page-level latching. Derby uses only exclusive latches, not shared latches in B+ tree implementation.

Foreign Keys


Foreign key is implemented as one of the CONSTAINT clauses. There are two levels of CONSTAINTS, column level and table level. Foreign key constraint in a column level enforces that the values in the column must corresponds to the values in the referenced column marked as primary key or unique key. Table level constraint works similarly, but it is for multiple columns.

Insert, update or delete instructions will be rejected with a statement exception if the foreign key constraint is violated. The constraint check can be at statement execution or commit depending on the constraint mode. (IMMEDIATE or DEFERRED).

Concurrency Control

Not Supported

There are row-level and table-level locks in Derby system to ensure data consistency. Also, deadlock detection is implemented such that the transaction that holds the least number of locks will be aborted. However, there is no deadlock prevention mechanisms. It depends on the correct application logics to prevent deadlocks.

Query Execution

Materialized Model

Subqueries can only be materialized if they not correlate with outer queries, and return one row. For subqueries that cannot be flattened (DISTINCT), optimization can be made on subqueries such as using Hash Join.

Isolation Levels

Read Uncommitted Read Committed Serializable Repeatable Read

It supports all four level of isolations. Isolation levels only differ for SELECT statements. They behave the same for other operations.

Storage Model

N-ary Storage Model (Row/Record)

Derby implements row-based storage model. Rows corresponds to records in data pages.


Nested Loop Join Hash Join

Derby provides two types of join strategies -- nested loop and hash join. Nested loop join is more preferable in most cases. Hash join is preferred when inner table values are unique and outer table have many qualifying rows. Also, when the system estimates that the amount of memory required for hash join exceeds the amount available, nested loop will be used.

Derby Logo

Source Code

Tech Docs


Cloudscape Inc.

Country of Origin


Start Year


Former Name

JBMS, Cloudscape, Java DB

Acquired By

Cloudscape Inc.

Project Type

Open Source

Written in


Supported languages


Operating Systems

All OS with Java VM


Apache v2