Editing SQLite (section)

==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 model|client–server]] database management systems, the SQLite engine has no standalone [[process (computing)|process]]es with which the application program communicates. Instead, a [[Linker (computing)|linker]] integrates the SQLite library{{emdash}}[[static library|statically]] or [[dynamic linker|dynamically]]{{emdash}}into an application program which uses SQLite's functionality through simple [[subroutine|function calls]], reducing [[latency (engineering)|latency]] in database operations; for simple queries with little concurrency, SQLite [[Computer performance|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>{{cite web |title = SQLite Is A Zero-Configuration Database |url = https://sqlite.org/zeroconf.html |access-date = August 3, 2015 |publisher = SQLite.org |archive-date = May 2, 2024 |archive-url = https://web.archive.org/web/20240502210736/https://sqlite.org/zeroconf.html |url-status = live }}</ref> because configuration tasks such as service management, startup scripts, and password- or [[Data control language|GRANT]]-based access control are unnecessary. [[Access-control list|Access control]] is handled through the [[file-system permissions]] of the database file.<ref name=":2">{{Cite web |title=SQLite |url=https://clickhouse.com/docs/en/engines/database-engines/sqlite |access-date=January 25, 2025 |website=ClickHouse Docs}}</ref> Databases in client–server systems use [[File system|file-system]] permissions that give access to the database files only to the [[Daemon (computing)|daemon]] process, which handles its locks internally, allowing [[Concurrency (computer science)|concurrent]] writes from several processes.

SQLite stores the entire database, consisting of definitions, [[Table (database)|tables]], indices, and data, as a single [[Cross-platform software|cross-platform]] file, allowing several processes or [[thread (computer science)|threads]] to access the same database concurrently. It implements this simple design by [[lock (computer science)|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 [[Computer multitasking|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>{{cite web |url = https://sqlite.org/wal.html |title = Write Ahead Logging in SQLite 3.7 |publisher = SQLite.org |access-date = September 3, 2011 |quote = WAL provides more concurrency as readers do not block writers and a writer does not block readers. Reading and writing can proceed concurrently. |archive-date = May 2, 2024 |archive-url = https://web.archive.org/web/20240502210711/https://sqlite.org/wal.html |url-status = live }}</ref> Since SQLite has to rely on file-system locks, it is not the preferred choice for write-intensive deployments.<ref>{{cite web |title = Appropriate Uses For SQLite |url = https://sqlite.org/whentouse.html |access-date = 2015-09-03 |publisher = SQLite.org |archive-date = 2024-05-02 |archive-url = https://web.archive.org/web/20240502210713/https://sqlite.org/whentouse.html |url-status = live }}</ref>

SQLite uses [[PostgreSQL]] as a reference platform. "What would PostgreSQL do" is used to make sense of the SQL standard.<ref>{{cite web |url=https://lwn.net/Articles/601144/ |title=PGCon 2014: Clustering and VODKA |website=Lwn.net |access-date=2017-01-06 |archive-date=2015-06-29 |archive-url=https://web.archive.org/web/20150629195442/https://lwn.net/Articles/601144/ |url-status=live }}</ref><ref>{{cite web |url=https://www.pgcon.org/2014/schedule/events/736.en.html |title=PGCon2014: SQLite: Protégé of PostgreSQL |website=Pgcon.org |date=20 September 2015 |access-date=2017-01-06 |archive-date=2014-12-30 |archive-url=https://web.archive.org/web/20141230193958/http://www.pgcon.org/2014/schedule/events/736.en.html |url-status=live }}</ref> One major deviation is that, with the exception of [[primary key]]s, SQLite does not enforce [[type checking]]; the type of a value is dynamic and not strictly constrained by the [[database schema|schema]] (although the schema will trigger a conversion when storing, if such a conversion is potentially reversible). SQLite strives to follow [[Robustness principle|Postel's rule]].<ref name=":1">{{cite web |title=SQLite: StrictMode |url=https://sqlite.org/src/wiki?name=StrictMode |url-status=live |archive-url=https://web.archive.org/web/20160304115940/https://sqlite.org/src/wiki?name=StrictMode |archive-date=March 4, 2016 |access-date=September 3, 2015 |website=Sqlite.org}}</ref>