This information is obsolete. You are looking at the
CVSTrac source management system display
for SQLite that was replaced by
Fossil on 2009-08-11. The
information shown here has not been updated since that cut-over.
These pages are retained for historical
reference only.

There are lots of database engines in the world.
There is a growing number of open-source embedded database engines.
How can you know which engine is right for your application?

This page provides links to comparisons between SQLite and
other database engines. The information that this page links to
is intended to provide designers with information to help them
choose the best database for their particular situation. If you
find additional comparision information, please add a link to this
page.

SqliteVersusRDMMobile - RDM-Mobile 3.0 from Birdstep Technology (http://www.birdstep.com/database) is basically the same product as RDM Embedded. It was extended with additional access layers (Java-JNI, XML).

SqliteVersusRDMEmbedded

RDM-Embedded (also from Birdstep Technology) adds a SQL-Layer to RDM-Mobile. It features an ODBC-like C-API. The SQL-Dialect is very limited compared to SQLite (no triggers, no views, no outer joins ...). No DDL-Statements can be executed via the SQL-Layer, the table structure must be predefined using a preprocessor utility. As the records are fixed-size the database can grow large but does support variable length strings.

What about EmbeddedMySQL?: (description) I
don't know enough to do a comparison myself, but it seems to have a lot of
overlap.

A big turn off for EmbeddedMySQL is their license - here's an extract:

"The MySQL source code is covered by the GNU GPL license (see section G GNU
General Public License). One result of this is that any program which includes,
by linking with libmysqld, the MySQL source code must be released as free
software (under a license compatible with the GPL)." (added by
DV)

Another turn off is its size: when i link SQLite into my app the difference is
barely noticed not so with EmbeddedMySQL.

SimpleSQL is only sparsely documented. The code is uncommented except
for a boiler-plate header comment on each file. There are some test cases
but the testing seems to be much less rigorous than SQLite. SimpleSQL uses
the LGPL license.

Berkeley DB (BDB) is just the data storage layer - it does not support
SQL or schemas. In spite of this, BDB is twice the size of
SQLite. A comparison between BDB and SQLite is similar to a comparison
between assembly language and a dynamic language like Python or Tcl.
BDB is probably much faster if you code it carefully. But it is much more
difficult to use and considerably less flexible.

On the other hand BDB has very fine grained locking (although it's not very well documented), while SQLite currently has only database-level locking.
-- fine grain locking is important for enterprise database engines, but much
less so for embedded databases. In SQLite, a writer gets a lock, does an
update, and releases the lock all in a few milliseconds. Other readers have
to wait a few milliseconds to access the database, but is that really ever
a serious problem?

SqliteVersusFirebird - SQLite versus Embedded Firebird SQL server : In the embedded version of FireBird (ie. the equivalent of SQLite vs. the client/server version) the database must reside on the host where the EXE is running, ie. it is discouraged to use a database on a remote host, such as (\\server\data\myfile.db) or (x:\data\myfile.db). This drawback can be circumvented though. However, an embedded server locks a database file for its own exclusive use after successful connection. This means that you cannot access the same database from multiple embedded server processes simultaneously (or from any other servers, once an embedded server has locked the file). The embedded server has no facility to accept any network connections. Only true local access is possible, with a connect string that doesn't contain a host name (not even localhost). see FirebirdSQL.org website

ITTIA DB has row-level locking, which allows larger concurrent transactions than SQLite's database-level locking, and UNDO-REDO logging, so that the page cache is not flushed at the end of every transaction. SQLite uses manifest typing, whereas ITTIA DB enforces data types.

See also 602SQL an interesting cross platform database a bit unknow till now, the project seems to be stopped but what's there is impressive.