Derby: The Java Relational Database

You have better things to do with your time and money than spend them on a database. Don’t short change yourself or your data — use Derby.

The information infrastructure of today’s organization is typically heterogenous. There are loosely-coupled web applications, tightly-coupled client-server applications, and even standalone applications, all running on multiple operating systems.

Given the disparate type and age of applications and the number and variety of platforms, it’s also typical to find many kinds of databases in use. (Except for the simplest programs, most applications need to persist data.) And while no database suits all requirements, you may find that the Derby relational database (http://incubator.apache.org/derby/) is appropriate for many. Derby is a full-featured relational database with a solid pedigree

Derby began life in 1996 as Cloudscape in a start-up of the same name, and it was used in production applications from the very beginning. Cloudscape was acquired by Informix, which was itself eventually acquired by IBM. Perceiving an opportunity to provide a database for all but the most demanding enterprise Java applications, IBM contributed Cloudscape to the Apache Software Foundation in the summer of 2004.

[ As this issue of Linux Magazine goes to press,] Derby is a podling project in the Apache Incubator where it enjoys an active community that’s poised to release version 10.1. (For more about the Apache Incubator, see the feature “The Apache Way” at http://www.linux-mag.com/content/view/2124/2304/.)

Derby Qualities and Commitments

Derby is a lightweight, open source, relational database written entirely in Java. Like other Java applications, Derby can run unchanged on any computer that has a Java Virtual Machine (JVM); moreover, a Derby database system can be copied verbatim between computer platforms and still work flawlessly! Derby can run between a client and server, but it can also be embedded in any Java program, adding just 2 MB to the application.

Better yet, Derby is reliable — and has been from its inception. To this day, Derby remains true to it’s original key principles:

*Focus on database technology and do it well. The Derby engine is transactional: all database operations ensure the integrity and recoverability of data. Derby provides full Atomicity, Consistency, Isolation, and Durability (ACID) transaction support at each of the four JDBC isolation levels (serializable, repeatable read, read committed, or dirty read). (See the sidebar “Transactions and Isolation Levels” for more information.)

*Play well with others. Derby is based on the JDBC and ANSI SQL standards and has the features of much larger database systems. If you use a standards-compliant database now, chances are that you can easily transition to or from Derby as business needs require. Being written entirely in Java allows Derby databases to be used unaltered on a variety of hardware platforms, anywhere there is a fully functional Java Virtual Machine (JVM).

*Zero administration. Designed to be used and managed by programmers (not database analysts), Derby requires no administration when used in it’s default configuration. All activity is automated or can be performed programmatically including starting and stopping the database engine. Copying the Derby .jar file to disk and setting the CLASSPATH variable installs Derby. This is often done in the application installation process without any end-user intervention. Moreover, Derby’s small footprint adds little bulk to most applications.

And, of course, Derby supports all of the features you’ve come to expect in a relational database, including crash recovery, transaction rollback and commit, row- and table-level locking, views, primary and foreign key constraints, triggers, BLOB and CLOB data types, sub-queries as expressions, encryption, and more. Derby is an easy-to-use, versatile, and full-featured database!