Documentation Source Text: Artifact Content

Artifact 4d09e86e87919e54abd9dadf88aafc411653a247:

File pages/serverless.in — part of check-in [1ac9233c15] at 2009-08-10 11:26:57 on branch trunk — Fix typo in serverless.html. (user: dan size: 1628)

<title>SQLite Is Serverless</title>

<h2>SQLite Is Serverless</h2>

<p>
Most SQL database engines are implemented as a separate server process.
Programs that want to access the database communicate with the server
using some kind of interprocess communication (typically TCP/IP) to send 
requests to the server and to receive back results. 
SQLite does not work this way. 
With SQLite, the process that wants to access the database reads and 
writes directly from the database files on disk. 
There is no intermediary server process.
</p>

<p>
There are advantages and disadvantages to being serverless.
The main advantage is that there is no separate server process
to install, setup, configure, initialize, manage, and troubleshoot. 
This is one reason why SQLite is a 
"<a href="zeroconf.html">zero-configuration</a>" database engine. 
Programs that use SQLite require no administrative support for 
setting up the database engine before they are run.
Any program that is able to access the disk is able to use an SQLite database.
</p>

<p>
On the other hand, a database engine that uses a server can 
provide better protection from bugs in the client 
application - stray pointers in a client cannot corrupt memory 
on the server. 
And because a server is a single persistent process,
it is able to control database access with more precision, 
allowing for finer grain locking and better concurrency.
</p>

<p>
Most SQL database engines are client/server based. 
Of those that are serverless, SQLite is the only one
known to this author that allows multiple applications
to access the same database at the same time. 
</p>