SQLite is an in-process library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. SQLite is the most widely deployed database in the world with 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. SQLite database files are a recommended storage format by the US Library of Congress. Think of SQLite not as a replacement for Oracle but as a replacement for fopen()
SQLite is a compact library. With all features enabled, the library size can be less than 600KiB, depending on the target platform and compiler optimization settings. (64-bit code is larger. And some compiler optimizations such as aggressive function inlining and loop unrolling can cause the object code to be much larger.) There is a tradeoff between memory usage and speed. It generally runs faster the more memory you give it. Nevertheless, performance is usually quite good even in low-memory environments. Depending on how it is used, SQLite can be faster than direct filesystem I/O.
- Added the sqlite3_txn_state() interface for reporting on the current transaction state of the database connection.
- Enhance recursive common table expressions to support two or more recursive terms as is done by SQL Server, since this helps make queries against graphs easier to write and faster to execute.
- Improved error messages on CHECK constraint failures.
- CLI enhancements:
- The .read dot-command now accepts a pipeline in addition to a filename.
- Added options –data-only and –nosys to the .dump dot-command.
- Added the –nosys option to the .schema dot-command.
- Table name quoting works correctly for the .import dot-command.
- The generate_series(START,END,STEP) table-valued function extension is now built into the CLI.
- The .databases dot-command now shows the status of each database file as determined by sqlite3_db_readonly() and sqlite3_txn_state().
- Added the –tabs command-line option that sets .mode tabs.
- The –init option reports an error if the file named as its argument cannot be opened. The –init option also now honors the –bail option.
- Query planner improvements:
- Improved estimates for the cost of running a DISTINCT operator.
- When doing an UPDATE or DELETE using a multi-column index where only a few of the earlier columns of the index are useful for the index lookup, postpone doing the main table seek until after all WHERE clause constraints have been evaluated, in case those constraints can be covered by unused later terms of the index, thus avoiding unnecessary main table seeks.
- The new OP_SeekScan opcode is used to improve performance of multi-column index look-ups when later columns are constrained by an IN operator.
- The BEGIN IMMEDIATE and BEGIN EXCLUSIVE commands now work even if one or more attached database files are read-only.
- Enhanced FTS5 to support trigram indexes.
- Improved performance of WAL mode locking primitives in cases where there are hundreds of connections all accessing the same database file at once.
- Enhanced the carray() table-valued function to include a single-argument form that is bound using the auxiliary sqlite3_carray_bind() interface.
- The substr() SQL function can now also be called “substring()” for compatibility with SQL Server.
- The syntax diagrams are now implemented as Pikchr scripts and rendered as SVG for improved legibility and ease of maintenance.