An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
SQLite Source Repository
This repository contains the complete source code for the
SQLite database engine going back
to 2000-05-29. The tree includes many tests and some
documentation, though additional tests and most documentation
are managed separately.
See the on-line documentation for more information
about what SQLite is and how it works from a user's perspective. This
README file is about the source code that goes into building SQLite,
not about how SQLite is used.
Version Control
SQLite sources are managed using
Fossil, a distributed version control system
that was specifically designed and written to support SQLite development.
The Fossil repository contains the urtext.
If you are reading this on GitHub or some other Git repository or service,
then you are looking at a mirror. The names of check-ins and
other artifacts in a Git mirror are different from the official
names for those objects. The official names for check-ins are
found in a footer on the check-in comment for authorized mirrors.
The official check-in name can also be seen in the manifest.uuid file
in the root of the tree. Always use the official name, not the
Git-name, when communicating about an SQLite check-in.
If you pulled your SQLite source code from a secondary source and want to
verify its integrity, there are hints on how to do that in the
Verifying Code Authenticity section below.
Contacting The SQLite Developers
The preferred way to ask questions or make comments about SQLite is to
visit the SQLite Forum at
https://sqlite.org/forum/. Anonymous postings are permitted. For
bug reports, please use the SQLite bugs
forum at https://sqlite.org/bugs.
If you think you have found a bug that has security implications and
you do not want to report it on the public forum, you can send a private
email to drh at sqlite dot org.
Public Domain
The SQLite source code is in the public domain. See
https://sqlite.org/copyright.html for details.
Because SQLite is in the public domain, we do not normally accept pull
requests, because if we did take a pull request, the changes in that
pull request might carry a copyright and the SQLite source code would
then no longer be fully in the public domain.
Obtaining The SQLite Source Code
Source code tarballs or ZIP archives are available at:
Latest trunk check-in.
Latest release
For other check-ins, browse the
project timeline and
click on the check-in hash of the check-in you want to download.
On the resulting "info" page, click one of the options to the
right of the "Downloads:" label in the "Overview" section
near the top.
To access sources directly using Fossil,
first install Fossil version 2.0 or later.
Source tarballs and precompiled binaries for Fossil are available at
https://fossil-scm.org/home/uv/download.html. Fossil is
a stand-alone program. To install, simply download or build the single
executable file and put that file someplace on your $PATH or %PATH%.
Then run commands like this:
mkdir -p ~/sqlite
cd ~/sqlite
fossil open https://sqlite.org/src
The initial "fossil open" command will take two or three minutes. Afterwards,
you can do fast, bandwidth-efficient updates to whatever versions of SQLite you
like. Some examples:
fossil update trunk ;# latest trunk check-in
fossil update release ;# latest official release
fossil update trunk:2024-01-01 ;# First trunk check-in after 2024-01-01
fossil update version-3.39.0 ;# Version 3.39.0
Or type "fossil ui" to get a web-based user interface.
Compiling for Unix-like systems
First create a directory in which to place
the build products. It is recommended, but not required, that the
build directory be separate from the source directory. Cd into the
build directory and then from the build directory run the configure
script found at the root of the source tree. Then run "make".
See the compile-for-unix.md document for
more detail.
For example:
apt install gcc make tcl-dev ;# Install the necessary build tools
tar xzf sqlite.tar.gz ;# Unpack the source tree into "sqlite"
mkdir bld ;# Build happens in a sibling directory
cd bld ;# Change to the build directory
../sqlite/configure ;# Run the configure script
make sqlite3 ;# The "sqlite3" command-line tool
make sqlite3.c ;# The "amalgamation" source file
make sqldiff ;# The "sqldiff" command-line tool
#### Targets below require tcl-dev ####
make tclextension-install ;# Install the SQLite TCL extension
make test ;# Run development tests
make releasetest ;# Run full release tests
make sqlite3_analyzer ;# Builds the "sqlite3_analyzer" tool
See the makefile for additional targets. For debugging builds, the
core developers typically run "configure" with options like this:
../sqlite/configure --all --debug CFLAGS='-O0 -g'
For release builds, the core developers usually do:
../sqlite/configure --all
Core deliverables (sqlite3.c, sqlite3) can be built without a TCL, but
many makefile targets require a "tclsh" TCL interpreter version 8.6
or later. The "tclextension-install" target and the test targets that follow
all require TCL development libraries too. ("apt install tcl-dev"). It is
helpful, but is not required, to install the SQLite TCL extension (the
"tclextension-install" target) prior to running tests. The "releasetest"
target has additional requirements, such as "valgrind".
On "make" command-lines, one can add "OPTIONS=..." to specify additional
compile-time options over and above those set by ./configure. For example,
to compile with the SQLITE_OMIT_DEPRECATED compile-time option, one could say:
./configure --all
make OPTIONS=-DSQLITE_OMIT_DEPRECATED sqlite3
The configure script uses autosetup.
If the configure script does not work out for you, there is a generic
makefil
Read the full README on GitHub
