Ittia (http://www.ittia.com/) released their database product "db.*" under an open-source license on or about 2004-Aug-12. _(Question: Is db.* a descendent of the Raima database engine?)_ Like SQLite, db.* is designed to be an embedded database engine. The 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 about 100KB. SQLite is over 2 times larger, approaching 250KB. Both db.* and SQLite have a runtime database cache which is adjustable in size. *Concurrency* Both db.* and SQLite appear to lock the entire database when making changes to the database. Db.* uses a lock manager which runs as a separate process. It might be possible to modify the lock manager to support table-level locking in db.*. *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* Both db.* and SQLite are open-source software. Db.* uses a modified Mozilla license. You are free to use db.* on any open-source operating system. SQLite is in the public domain. It is free for use for any purpose.