Documentation Source Text

  Most other SQL database engines require you to dump and restore
  the database when moving from one platform to another and often
  when upgrading to a newer version of the software.
}

feature small {Compact} {
  When optimized for size, the whole SQLite library with everything enabled
  is [footprint | less than 400KiB in size]
  (as measured on an ix86 using the "size"
  utility from the GNU compiler suite.)  Unneeded features can be disabled
  at compile-time to further reduce the size of the library to under
  190KiB if desired.
  <p>
  Most other SQL database engines are much larger than this.  IBM boasts
  that its recently released CloudScape database engine is "only" a 2MiB
  jar file - an order of magnitude larger than SQLite even after it is
  compressed!
  Firebird boasts that its client-side library is only 350KiB.  That's
  as big as SQLite and does not even contain the database engine.

  This document describes the SQL language that is understood by
  SQLite.  
}
doc {Pragma commands} {pragma.html} {
  This document describes SQLite performance tuning options and other 
  special purpose database commands.
}
doc {Version 3 DataTypes } {datatype3.html} {
  SQLite version 3 introduces the concept of manifest typing, where the
  type of a value is associated with the value itself, not the column that
  it is stored in.
  This page describes data typing for SQLite version 3 in further detail.
}
doc {Null Handling} {nulls.html} {
  Different SQL database engines handle NULLs in different ways.  The
  SQL standards are ambiguous.  This document describes how SQLite handles
  NULLs in comparison with other SQL database engines.
}
doc {Unsupported SQL} {omitted.html} {
  This page describes features of SQL that SQLite does not support.
}


heading {SQLite Features and Extensions} {
  Pages describing specific features or extension modules of SQLite.
}
doc {Autoincrement} {autoinc.html} {
  A description of the AUTOINCREMENT keyword in SQLite, what it does,

}
doc {Using The Online Backup Interface} {backup.html} {
  The [sqlite3_backup_init | online-backup interface] can be used to
  copy content from a disk file into an in-memory database or vice
  versa and it can make a hot backup of a live database.  This application
  note gives examples of how.
}










heading {Upgrading SQLite, Backwards Compatibility}

doc {Moving From SQLite 3.5 to 3.6} {35to36.html} {
  A document describing the differences between SQLite version 3.5.9
  and 3.6.0.
}

doc {Limits In SQLite} {limits.html} {
  This document describes limitations of SQLite (the maximum length of a
  string or blob, the maximum size of a database, the maximum number of
  tables in a database, etc.) and how these limits can be altered at
  compile-time and run-time.
}











heading {Obsolete Documents} {
  These documents either pertain to SQLite version 2 or were written
  during the transition period between versions 2 and 3 (circa 2004).
  This documents are no longer up-to-date.  They are retained for 

<title>Appropriate Uses For SQLite</title>

<h2>Appropriate Uses For SQLite</h2>

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

<ul>
<li>Simple to administer</li>
<li>Simple to operate</li>
<li>Simple to embed in a larger program</li>
<li>Simple to maintain and customize</li>
</ul>

<p>
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.
</p>

<p>
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 some of these
features and do not 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 is
not designed to compete with Oracle or PostgreSQL.
</p>

<p>
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 than many people realize.
</p>

<p>
Another way to look at SQLite is this:  SQLite is not designed
to replace [http://www.oracle.com/database/index.html | Oracle].
It is designed to replace [http://man.he.net/man3/fopen | fopen()].
</p>

<h2>Situations Where SQLite Works Well</h2>

<ul>

<tcl>hd_fragment appfileformat</tcl>