Small. Fast. Reliable.
Choose any three.
Birdstep (http://www.birdstep.com/database) released their database product "db.*" under an open-source license around 2000. It is a descendent of the Raima database engine (see http://www.birdstep.com/database/products/rdm-embedded for more information). Like SQLite, db.* is designed to be an embedded database engine. This page provides a comparison of the two products to aid designers in choosing a product that is right for them.

The information on this page about db.* is based primarily on a reading of the on-line documentation for db.*. All information is believed to be correct. However, the author is not a db.* expert and so there could be errors. If you see any errors or omissions you are encouraged to make corrections.

Fundamental Differences

Db.* is designed to be embedded in a C/C++ application and access data using a library of C function calls. It does not have an SQL layer. The emphasis is on small size.

SQLite is an embedded SQL database engine. It is larger than db.* but provides the power of SQL in order to make application development easier.

On-disk Database Representation

SQLite stores all information for an entire database in a single cross-platform disk file. Db.* stores each table and index in s separate disk file. The file format used by db.* is not portable between big-endian and little-endian machines. (To be fair to db.*, it appears to be designed for use on embedded hardware where cross-platform is never a concern.)

Db.* uses a fixed record size (defined at compile time) for all records in a single table. SQLite uses a variable-length records everywhere.

No direct comparision of the database sizes is available. However, based on the file formats one would expect a db.* database to use less disk space when all records are nearly the same size (contain strings with the same number of characters and numeric values of the same magnitude.) When records are of varying size, SQLite database files are expected to be smaller.

Data Integrity

Both db.* and SQLite provide transaction data integrity. If a program or OS crash or a power failure interrupts a database change, the change is either automatically completed or rolled back after the next reboot. The database is not corrupted by an incomplete write operation.

Database Access Methodology

Db.* uses a library of C/C++ routines to read and write the database. The database uses a fixed schema that must be defined before the application is compiled. Parts of the database layer are recorded in automatically generated C header files. Any change to the database schema requires that the application be recompiled.

SQLite uses the SQL query language to both define the database schema at runtime and to read and write data from the database. SQLite is able to handle varying database schemas without requiring a recompilation.

Both db.* and SQLite read and write directly from disk through a page cache. This is in contrast to other embedded database engines (ex: HSQLDB) that read the entire database into memory and operate from in-memory data structures.

Memory Utilization

Db.* claims a code footprint of 216KB. SQLite is approaching 250KB. Both db.* and SQLite have a runtime database cache which is adjustable in size.

Concurrency

db.* locks a table (or file) when making a change to the database while SQLite lock the entire database. Db.* uses a lock manager which runs in shared memory or as a separate process.

Host Language Support

Db.* appears to be supported for C/C++ programs only. One could, of course, create db.* bindings for popular scripting languages or for java, but the bindings themselves would need to be recompiled whenever the database schema changed so this seem impractical.

SQLite is written in C but supports bindings to dozens of different programming languages.

License

SQLite is in the public domain. It is free for use for any purpose.

The db.* licensed under Centura Open-Source License now owned by Birdstep Technology (http://www.birdstep.com/database)