Small. Fast. Reliable.
Choose any three.

Appropriate Uses For SQLite

SQLite is not directly comparable to other SQL database engines such as Oracle, PostgreSQL, MySQL, or SQL Server since SQLite is trying to solve a very different problem.

Other SQL database engines strive to implement a shared repository of enterprise data. They emphasis scalability, concurrency, centralization, and control.

SQLite, on the other hand, strives to provide local data storage for individual applications and devices. SQLite emphasizes economy, efficiency, reliability, independence, and simplicity.

SQLite is not designed to compete with Oracle. SQLite is designed to compete with fopen().

Situations Where SQLite Works Well

Situations Where Another RDBMS May Work Better

Checklist For Choosing A Database Engine

  1. Is the data separated from the application by a network? → choose client/server

    Relational database engines act as a bandwidth-reducing data filter. So it is best to keep the database engine and the data on the same physical device so that the high-bandwidth engine-to-disk link does not have to traverse the network, only the lower-bandwidth application-to-engine link.

    But SQLite is built into the application. So if the data is on a separate device from the application, it is required that the higher bandwidth engine-to-disk link be across the network. This works, but it is suboptimal. Hence, it is usually better to select a client/server database engine when the data is on a separate device from the application.

  2. Concurrent writers? → choose client/server

    If two or more threads or processes need to write the database at the same instant (and they cannot queue up and take turns) then it is best to select a database engine that supports that capability, which always means a client/server database engine.

  3. Big data? → choose client/server

    If your data will grow to a size that you are uncomfortable or unable to fit into a single disk file, then you should select a solution other than SQLite. SQLite supports databases up to 140 terabytes in size, assuming you can find a disk drive and filesystem that will support 140-terabyte files. Even so, when the size of the content looks like it might creep into the terabyte range, it would be good to consider a centralized client/server database.

  4. Otherwise → choose SQLite!

    For device-local storage with low writer concurrency and less than a terabyte of content, SQLite is almost always a better solution. SQLite is fast and reliable and it requires no configuration or maintenance. It keeps thing simple. SQLite "just works".