SQLite

SQLite is an in-process library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine.

The code for SQLite is in the public domain and is thus free for use for any purpose, commercial or private. SQLite is currently found in more applications than we can count, including several high-profile projects. SQLite is an embedded SQL database engine. Unlike most other SQL databases, SQLite does not have a separate server process. SQLite reads and writes directly to ordinary disk files. A complete SQL database with multiple tables, indices, triggers, and views, is contained in a single disk file.

The database file format is cross-platform - you can freely copy a database between 32-bit and 64-bit systems or between big-endian and little-endian architectures. These features make SQLite a popular choice as an Application File Format. Think of SQLite not as a replacement for Oracle but as a replacement for fopen() If you need a GUI for database management, you can install NAVICAT. SQLite is a compact library. With all features enabled, the library size can be less than 300KiB, depending on compiler optimization settings. (Some compiler optimizations such as aggressive function inlining and loop unrolling can cause the object code to be much larger.) If optional features are omitted, the size of the SQLite library can be reduced below 180KiB.

SQLite can also be made to run in minimal stack space (4KiB) and very little heap (100KiB), making SQLite a popular database engine choice on memory constrained gadgets such as cellphones, PDAs, and MP3 players. There is a tradeoff between memory usage and speed. SQLite generally runs faster the more memory you give it. Nevertheless, performance is usually quite good even in low-memory environments.

Optimization:

• When doing an UPDATE on a table with indexes on expressions, do not update the expression indexes if they do not refer to any of the columns of the table being updated.
• Allow the xBestIndex() method of virtual table implementations to return SQLITE_CONSTRAINT to indicate that the proposed query plan is unusable and should not be given further consideration.
• Added the SQLITE_DBCONFIG_DEFENSIVE option which disables the ability to create corrupt database files using ordinary SQL.
• Added support for read-only shadow tables when the SQLITE_DBCONFIG_DEFENSIVE option is enabled.
• Added the PRAGMA legacy_alter_table command, which if enabled causes the ALTER TABLE command to behave like older version of SQLite (prior to version 3.25.0) for compatibility.
• Added PRAGMA table_xinfo that works just like PRAGMA table_info except that it also shows hidden columns in virtual tables.
• Added the explain virtual table as a run-time loadable extension.
• Add a limit counter to the query planner to prevent excessive sqlite3_prepare() times for certain pathological SQL inputs.
• Added support for the sqlite3_normalized_sql() interface, when compiling with SQLITE_ENABLE_NORMALIZE.
• Enhanced triggers so that they can use table-valued functions that exist in schemas other than the schema where the trigger is defined.

Enhancements to the CLI:

• Improvements to the ".help" command.
• The SQLITE_HISTORY environment variable, if it exists, specifies the name of the command-line editing history file
• The --deserialize option associated with opening a new database cause the database file to be read into memory and accessed using the sqlite3_deserialize() API. This simplifies running tests on a database without modifying the file on disk.

Enhancements to the geopoly extension:

• Aways stores polygons using the binary format, which is faster and uses less space.
• Added the geopoly_regular() function.
• Added the geopoly_ccw() function.

Enhancements to the session extension:

• Added the SQLITE_CHANGESETAPPLY_INVERT flag
• Added the sqlite3changeset_start_v2() interface and the SQLITE_CHANGESETSTART_INVERT flag.
• Added the changesetfuzz.c test-case generator utility.