Logo OS Reviews

Reviewing Freedom.



Embedded SQL that 'just works'

Hendrik Weimer


Print version

Slashdot me! Digg me! Stumble me! del.icio.us

Almost all modern database systems provide an SQL interface for viewing and manipulating the stored data. Although an ISO standard exists for the language, SQL code is barely portable for a variety of reasons. This puts an application programmer into the unpleasant position to either support several different database back-ends or force the user to go with a specific vendor. Extra fun is added when the user has to run multiple versions of the same product due to broken backward compatibility.

There is a third way, however. You can build your application with an embedded SQL library like SQLite. In several ways, SQLite is completely different to the usual database systems:

  • There is no server running. All operations are done in the context of the application linking against SQLite.
  • Instead of a database socket, communication with SQLite is done via function calls from within the application. Bindings for several languages exist.
  • The entire database is located in a single file.
  • SQLite requires only a few hundred kilobytes of hard disk space compared to the dozens of megabytes for a database server.

If you use an abstract database interface like DBI for Perl, you won't notice much of these things. You will only have to change your code concerning different SQL extensions, which shouldn't cause major trouble.

Databases are created simply by opening them. You can immediately create tables, insert data and all other things you like. A command-line tool is available as well, which is very similar to those accompanying the major database servers.

SQLite offers a pretty robust database model that supports transactions. These are implemented using file locking mechanisms of the operating system. Therefore, if a process wants to write to the database, all other process have to wait for read or write access until the transaction has been completed. This is of course a drawback in an environment where high concurrency is required, but should not be relevant in most situations. Transactions in SQLite fulfill the ACID (Atomic, Consistent, Isolated, Durable) properties.

When playing around with SQLite you will notice that there only few functions available. Some date and time conversions are possible, but mathematical and string functions are nonexistent. This is a downside, but you will probably be able to perform these operations within your application.

To be honest, not every application allows to use an embedded SQL library. Besides high concurrency requirements, very large databases (i.e. more than several GB) or high-volume websites are probably better off with a conventional system. The SQLite documentation offers some insight on when to use it and when not to. But there is no excuse for every tiny web application to require MySQL or PostgreSQL.

To quote the SQLite documentation: "SQLite just works." It is the right choice whenever you can avoid to use a large database server. Especially web developers should do their users a favor and get rid of unnecessary dependencies.

Got a question on SQLite? Post it as a comment!

License:Public Domain
Distributions: [?]■ Debian stable■ Debian unstable
■ Fedora■ Mandriva
■ Suse■ Ubuntu


  • Easy deployment
  • Transaction support
  • Few embedded functions

Copyright 2006–2008 OS Reviews. This document is available under the terms of the GNU Free Documentation License. See the licensing terms for further details.

  • Advertisement