# # Run this TCL script to generate HTML for the goals.html file. # set rcsid {$Id: whentouse.tcl,v 1.2 2004/10/10 17:24:55 drh Exp $} puts { Appropriate Uses of SQLite

Appropriate Uses Of SQLite

} puts "

(This page was last modified on [lrange $rcsid 3 4] UTC)

" puts {

SQLite is different from most other SQL database engines in that its primary design goal is to be simple:

Many people like SQLite because it is small and fast. But those qualities are just happy accidents. Users also find that SQLite is very reliable. Reliability is a consequence of simplicity. With less complication, there is less to go wrong. So, yes, SQLite is small, fast, and reliable, but first and foremost, SQLite strives to be simple.

Simplicity in a database engine can be either a strength or a weakness, depending on what you are trying to do. In order to achieve simplicity, SQLite has had to sacrifice other characteristics that some people find useful, such as high concurrency, fine-grained access control, a rich set of built-in functions, stored procedures, esoteric SQL language features, XML and/or Java extensions, tera- or peta-byte scalability, and so forth. If you need these kinds of features and don't mind the added complexity that they bring, then SQLite is probably not the database for you. SQLite is not intended to be an enterprise database engine. It not designed to compete with Oracle or PostgreSQL.

The basic rule of thumb for when it is appropriate to use SQLite is this: Use SQLite in situations where simplicity of administration, implementation, and maintenance are more important than the countless complex features that enterprise database engines provide. As it turns out, situations where simplicity is the better choice are more common that many people realize.

Situations Where SQLite Works Well

Situations Where Another RDBMS May Work Better

} puts {

Back to the SQLite home page