SQLite

From Vero - Wikipedia
Jump to navigation Jump to search

Template:Short description Template:Infobox software Template:Infobox file format

SQLite (Template:IPAc-en "S-Q-L-ite",<ref>Template:Cite episode</ref><ref>Template:Cite video</ref> Template:IPAc-en "sequel-ite"<ref>Template:Cite video</ref>) is a free and open-source relational database engine written in the C programming language. It is not a standalone app; rather, it is a library that software developers embed in their apps. As such, it belongs to the family of embedded databases. According to its developers, SQLite is the most widely deployed database engine, as it is used by several of the top web browsers, operating systems, mobile phones, and other embedded systems.<ref>Template:Cite web</ref>

Many programming languages have bindings to the SQLite library. It generally follows PostgreSQL syntax, but does not enforce type checking by default.<ref name="Owens 2006">Template:Cite book</ref><ref>Template:Cite web</ref> This means that one can, for example, insert a string into a column defined as an integer. Although it is a lightweight embedded database, SQLite implements most of the SQL standard and the relational model, including transactions and ACID guarantees.<ref>Template:Cite web</ref> However, it omits many features implemented by other databases, such as materialized views and complete support for triggers and ALTER TABLE statements.<ref>Template:Cite web</ref>

History

D. Richard Hipp designed SQLite in the spring of 2000 while working for General Dynamics on contract with the United States Navy.<ref name="Owens06">Template:Cite book</ref> Hipp was designing software used for a damage-control system aboard guided-missile destroyers; the damage-control system originally used HP-UX with an Informix database back-end. SQLite began as a Tcl extension.<ref name=":0" />

In August 2000, version 1.0 of SQLite was released, with storage based on gdbm (GNU Database Manager). In September 2001, SQLite 2.0 replaced gdbm with a custom B-tree implementation,Template:Efn adding transaction capability. In June 2004, SQLite 3.0 added internationalization, manifest typing, and other major improvements, partially funded by America Online. In 2011, Hipp announced his plans to add a NoSQL interface to SQLite, as well as announcing UnQL, a functional superset of SQL designed for document-oriented databases.<ref name="unql-interview">Template:Cite web</ref>

SQLite is one of four formats recommended for long-term storage of datasets approved for use by the Library of Congress.<ref>Template:Cite web</ref><ref>Template:Cite web</ref><ref>Template:Cite web</ref>

Design

SQLite was designed to allow the program to be operated without installing a database management system or requiring a database administrator. Unlike client–server database management systems, the SQLite engine has no standalone processes with which the application program communicates. Instead, a linker integrates the SQLite libraryTemplate:Emdashstatically or dynamicallyTemplate:Emdashinto an application program which uses SQLite's functionality through simple function calls, reducing latency in database operations; for simple queries with little concurrency, SQLite performance profits from avoiding the overhead of inter-process communication.

Due to the serverless design, SQLite applications require less configuration than client–server databases. SQLite is called zero-configuration<ref>Template:Cite web</ref> because configuration tasks such as service management, startup scripts, and password- or GRANT-based access control are unnecessary. Access control is handled through the file-system permissions of the database file.<ref name=":2">Template:Cite web</ref> Databases in client–server systems use file-system permissions that give access to the database files only to the daemon process, which handles its locks internally, allowing concurrent writes from several processes.

SQLite stores the entire database, consisting of definitions, tables, indices, and data, as a single cross-platform file, allowing several processes or threads to access the same database concurrently. It implements this simple design by locking the database file during writing.<ref name=":2" /> Write access may fail with an error code, or it can be retried until a configurable timeout expires. SQLite read operations can be multitasked, though due to the serverless design, writes can only be performed sequentially. This concurrent access restriction does not apply to temporary tables, and it is relaxed in version 3.7 as write-ahead logging (WAL) enables concurrent reads and writes.<ref>Template:Cite web</ref> Since SQLite has to rely on file-system locks, it is not the preferred choice for write-intensive deployments.<ref>Template:Cite web</ref>

SQLite uses PostgreSQL as a reference platform. "What would PostgreSQL do" is used to make sense of the SQL standard.<ref>Template:Cite web</ref><ref>Template:Cite web</ref> One major deviation is that, with the exception of primary keys, SQLite does not enforce type checking; the type of a value is dynamic and not strictly constrained by the schema (although the schema will trigger a conversion when storing, if such a conversion is potentially reversible). SQLite strives to follow Postel's rule.<ref name=":1">Template:Cite web</ref>

Features

SQLite implements most of the SQL-92 standard for SQL, but lacks some features. For example, it only partially provides triggers and cannot write to views (however, it provides INSTEAD OF triggers that provide this functionality). Its support of ALTER TABLE statements is limited.<ref>Template:Cite web</ref>

SQLite uses an unusual type system for an SQL-compatible DBMS: instead of assigning a type to a column as in most SQL database systems, types are assigned to individual values; in language terms it is dynamically typed. Moreover, it is weakly typed in some of the same ways that Perl is: one can insert a string into an integer column (although SQLite will try to convert the string to an integer first, if the column's preferred type is integer). This adds flexibility to columns, especially when bound to a dynamically typed scripting language. However, the technique is not portable to other SQL products. A common criticism is that SQLite's type system lacks the data integrity mechanism provided by statically typed columns, although it can be emulated with constraints like <syntaxhighlight lang="sql" class="" style="" inline="1">CHECK(typeof(x)='integer')</syntaxhighlight>.<ref name="Owens06" /> In 2021, support for static typing was added through STRICT tables, which enforce datatype constraints for columns.<ref>Template:Cite web</ref>

Tables normally include a hidden rowid index column, which provides faster access.<ref>Template:Cite web</ref> If a table includes an INTEGER PRIMARY KEY column, SQLite will typically optimize it by treating it as an alias for the rowid, causing the contents to be stored as a strictly typed 64-bit signed integer and changing its behavior to be somewhat like an auto-incrementing column. SQLite includes an option to create a table without a rowid column, which can save disk space and improve lookup speed. WITHOUT ROWID tables are required to have a primary key.<ref>Template:Cite web</ref>

SQLite supports foreign key constraints,<ref>Template:Cite book</ref><ref>Template:Cite web</ref> although they are disabled by default and must be manually enabled with a PRAGMA statement.<ref>Template:Cite web</ref>

Stored procedures are not supported; this is an explicit choice by the developers to favor simplicity, as the typical use case of SQLite is to be embedded inside a host application that can define its own procedures around the database.<ref>Source: developers' comments on SQLite forum Template:Webarchive</ref>

SQLite does not have full Unicode support by default for backwards compatibility and due to the size of the Unicode tables, which are larger than the SQLite library.<ref>Template:Cite web</ref> Full support for Unicode case-conversions can be enabled through an optional extension.<ref>Template:Cite web</ref>

SQLite supports full-text search through its FTS5 loadable extension, which allows users to efficiently search for a keyword in a large number of documents similar to how search engines search webpages.<ref>Template:Cite web</ref>

SQLite includes support for working with JSON through its json1 extension, which is enabled by default since 2021. SQLite's JSON functions can handle JSON5 syntax since 2023. In 2024, SQLite added support for JSONB, a binary serialization of SQLite's internal representation of JSON. Using JSONB allows applications to avoid having to parse the JSON text each time it is processed and saves a small amount of disk space.<ref>Template:Cite web</ref>

In May 2025, the 25th‑anniversary release SQLite 3.50.0 introduced additional features, including new Unicode functions (<syntaxhighlight lang="text" class="" style="" inline="1">unistr()</syntaxhighlight> and <syntaxhighlight lang="text" class="" style="" inline="1">unistr_quote()</syntaxhighlight>), a new API (<syntaxhighlight lang="text" class="" style="" inline="1">sqlite3_setlk_timeout()</syntaxhighlight>) for setting lock timeouts, improved command‑line tools and rsync utility enhancements, and optimized JSONB.<ref>Template:Cite web</ref>

The maximum supported size for an SQLite database file is 281 terabytes.<ref>Template:Cite web</ref>

Development and distribution

SQLite's code is hosted with Fossil, a distributed version control system that uses SQLite as a local cache for its non-relational database format, and SQLite's SQL as an implementation language.<ref>Template:Cite web</ref><ref>Template:Cite web</ref>

SQLite is public domain, but not "open-contribution", with the website stating "the project does not accept patches from people who have not submitted an affidavit dedicating their contribution into the public domain."<ref>Template:Cite web</ref> Instead of a code of conduct, the founders have adopted a code of ethics based on the Rule of St. Benedict.<ref>Template:Cite web</ref>

A standalone command-line shell program called sqlite3<ref>Template:Cite web</ref> is provided in SQLite's distribution. It can be used to create a database, define tables, insert and change rows, run queries and manage an SQLite database file. It also serves as an example for writing applications that use the SQLite library.

SQLite uses automated regression testing prior to each release. Over 2 million tests are run as part of a release's verification. The SQLite library has 156,000 lines of source code, while all the test suites combined add up to 92 million lines of test code. SQLite's tests simulate a number of exceptional scenarios, such as power loss and I/O errors, in addition to testing the library's functionality. Starting with the August 10, 2009 release of SQLite 3.6.17, SQLite releases have 100% branch test coverage, one of the components of code coverage. SQLite has four different test harnesses: the original public-domain TCL tests, the proprietary C-language TH3 test suite, the SQL Logic Tests, which check SQLite against other SQL databases, and the dbsqlfuzz proprietary fuzzing engine.<ref name="tests">Template:Cite web</ref>

Template:AnchorNotable uses

Operating systems

SQLite is included by default in:<ref name=":0" />

Middleware

Web browsers

Web application frameworks

Others

See also

Template:Portal

Notes

Template:Notelist

References

Citations

Template:Reflist

Sources

Template:Refbegin

Template:Refend

Further reading

Template:Commons category

Template:Authority control

Retrieved from "https://wiki.sarg.dev/index.php?title=SQLite&oldid=165832"