SQLite was working well enough to be used in an experimental capacity in some commercial projects as early as 2000-Jun-11. The first official release of version 1.0 occurred on 2000-Aug-17.
Versions 1.0 through 1.0.32 of SQLite used the GDBM library as a database backend for reading and writing to disk. GDBM has a lot of limitations. GDBM only stores a single table per file, so a complete database consisted of a directory full of files - one file for each table and index. GDBM is based on hashing, so only exact key matches could be used on indices and inequality constraints required complete table scans. GDBM does not support atomic transactions. And GDBM is released under the GPL which meant that SQLite could not be embedded in proprietary products. Because of these constraints, work was begun on a new B-Tree based backend for SQLite in January of 2001.
Version 2.0.0 of SQLite, using the new B-Tree backend, was first released on 2001-Sep-11. Some incompatible file format changes were made for the 2.1.0 release on 2001-Nov-12, but since that time, all releases of SQLite have been backwards compatible in the sense that they could read and usually write older database files. Since version 2.1.0, most of the work on SQLite has been to add features, bring it into closer compliance with SQL-92, and make it run faster. SQLite is currently in active use in many (often familiar) desktop applications and embedded in consumer electronic devices.
Throughout its development, the design goals of SQLite have been as following and in order:
- Simplicity
- Reliability
- Correctness
- Speed
- Features
Above all, we strive to keep SQLite simple: simple to administer, simple to operate, simple to embed in other programs, and simple to maintain and customize. This is different from traditional SQL RDBMSes which tend to favor features and speed over simplicity. But that is ok. SQLite does not aspire to compete with Oracle or PostgreSQL. Enterprise database engines have their place and SQLite has its place. The two approaches to databases are both useful and can peacefully coexist. (See also: WhenToUseSqlite)
Current development efforts for SQLite are directed toward simplifying the existing code base - keeping all of the same features but implementing them with fewer lines of code and in ways that are easier understand and maintain. New features are planned (better BLOB support, AUTOINCREMENT, ALTER TABLE, referential integrity, WITH and WITH RECURSIVE, and so forth) but the first priority will continue to be to keep the code simple and easy to use.