How to Install SQLite on Fedora Linux

Fedora already gives you a stable SQLite build for scripts, local apps, and quick database work, but upstream releases usually land on sqlite.org first. When you need to install SQLite on Fedora, the package name is sqlite, and it provides the sqlite3 command-line shell.

This walkthrough covers the Fedora repository method, a source build under /usr/local for the newest upstream release, a quick write test, SELinux labeling for web apps, troubleshooting, updates, and removal.

Install SQLite on Fedora

Fedora’s repository is the right starting point for most systems, while a source build makes sense when you need a newer release before it reaches the distro package. The table below compares both supported paths.

Method	Source	Version Track	Updates	Best For
Fedora package	Fedora repositories	Fedora-tested stable release	Automatic through dnf upgrade	Most users who want the simplest maintenance path
Source build	SQLite upstream	Latest upstream release	Manual, or with the update script below	Developers who need a newer CLI or library right away

Start with the Fedora package unless you specifically need a newer upstream build. It keeps SQLite inside the normal DNF update flow and avoids manual cleanup later.

Install SQLite from Fedora’s repositories

The repository method installs Fedora’s current SQLite build and makes the sqlite3 shell available in your normal PATH.

sudo dnf upgrade --refresh

This guide uses sudo for commands that need root privileges. If your account does not have sudo access yet, follow the guide on how to add a user to sudoers on Fedora before continuing.

sudo dnf install sqlite

Verify the installation with the SQLite shell version command:

sqlite3 --version

3.50.2 2025-06-28 14:00:48 2af157d77fb1304a74176eaee7fbc7c7e932d946bf25325e9c26c91db19ealt1 (64-bit)

Use sudo dnf install sqlite, not sudo dnf install sqlite3. Fedora does not publish a separate sqlite3 package, so dnf info sqlite3 returns No matching packages to list.

Compile the latest SQLite source on Fedora

This method installs the newest upstream SQLite build under /usr/local. That keeps Fedora’s packaged files under /usr intact and lets the source build take priority through the default /usr/local/bin PATH entry.

Install SQLite build tools on Fedora

sudo dnf install gcc make curl tar

SQLite has no required third-party build dependencies for the standard CLI build, so these base tools are enough on current Fedora releases. SQLite’s own compile notes still boil down to a straightforward ./configure and make workflow on Unix-like systems.

Download and extract the SQLite source archive

mkdir -p ~/sqlite-source
cd ~/sqlite-source
SQLITE_TARBALL=$(curl -fsSL https://www.sqlite.org/download.html | grep -oE '[0-9]{4}/sqlite-autoconf-[0-9]+\.tar\.gz' | head -1)
curl -fLO "https://www.sqlite.org/$SQLITE_TARBALL"
tar -xzf sqlite-autoconf-*.tar.gz

SQLite encodes release numbers in the archive filename. For example, SQLite 3.51.2 downloads as sqlite-autoconf-3510200.tar.gz, where the trailing 00 is part of SQLite’s upstream numbering format.

Configure, compile, and install the SQLite source build

SQLITE_SOURCE_DIR=$(find ~/sqlite-source -maxdepth 1 -type d -name 'sqlite-autoconf-*' | head -1)
cd "$SQLITE_SOURCE_DIR"
./configure --prefix=/usr/local
make -j"$(nproc)"
sudo make install
sudo ldconfig

Check which SQLite binary is active and confirm the source version is now first in your PATH:

which sqlite3
sqlite3 --version

/usr/local/bin/sqlite3
3.51.2 2026-01-09 17:27:48 b270f8339eb13b504d0b2ba154ebca966b7dde08e40c3ed7d559749818cb2075 (64-bit)

Fedora’s packaged binary remains available at /usr/bin/sqlite3. Removing the source build later drops you back to the repository version instead of leaving the system without SQLite.

Update a source-compiled SQLite build

If you choose the source method, keep a small update script in your home directory so you can rebuild SQLite without repeating the download and version-parsing steps manually.

tee ~/update-sqlite.sh > /dev/null <<'SCRIPT'
#!/usr/bin/env bash
set -euo pipefail

# Verify the required tools before downloading a new release.
for cmd in curl gcc make tar; do
  if ! command -v "$cmd" > /dev/null; then
    echo "Missing required command: $cmd"
    echo "Install it with: sudo dnf install curl gcc make tar"
    exit 1
  fi
done

LATEST_TARBALL=$(curl -fsSL https://www.sqlite.org/download.html | grep -oE '[0-9]{4}/sqlite-autoconf-[0-9]+\.tar\.gz' | head -1)
if [[ -z "$LATEST_TARBALL" ]]; then
  echo "Could not detect the latest SQLite source archive from sqlite.org."
  exit 1
fi

LATEST_DIGITS=$(basename "$LATEST_TARBALL" .tar.gz | sed 's/sqlite-autoconf-//')
MAJOR=${LATEST_DIGITS::-6}
MINOR=${LATEST_DIGITS: -6:2}
PATCH=${LATEST_DIGITS: -4:2}
LATEST_VERSION="$MAJOR.$((10#$MINOR)).$((10#$PATCH))"

if command -v sqlite3 > /dev/null; then
  CURRENT_VERSION=$(sqlite3 --version | awk 'NR==1 {print $1}')
else
  CURRENT_VERSION="none"
fi

echo "Current installed version: $CURRENT_VERSION"
echo "Latest upstream version: $LATEST_VERSION"

if [[ "$CURRENT_VERSION" == "$LATEST_VERSION" ]]; then
  echo "SQLite is already up to date."
  exit 0
fi

BUILD_DIR=$(mktemp -d)
trap 'rm -rf "$BUILD_DIR"' EXIT
cd "$BUILD_DIR"

echo "Downloading SQLite $LATEST_VERSION..."
curl -fLO "https://www.sqlite.org/$LATEST_TARBALL"

echo "Extracting source archive..."
tar -xzf sqlite-autoconf-*.tar.gz
BUILD_SOURCE_DIR=$(find . -maxdepth 1 -type d -name 'sqlite-autoconf-*' | head -1)
if [[ -z "$BUILD_SOURCE_DIR" ]]; then
  echo "Could not locate the extracted SQLite source directory."
  exit 1
fi

cd "$BUILD_SOURCE_DIR"

echo "Configuring the build under /usr/local..."
./configure --prefix=/usr/local

echo "Compiling SQLite..."
make -j"$(nproc)"

echo "Installing SQLite..."
sudo make install
sudo ldconfig

echo "Installed version: $(/usr/local/bin/sqlite3 --version | awk 'NR==1 {print $1}')"
SCRIPT
chmod +x ~/update-sqlite.sh

Run the script whenever you want to check for a newer upstream release:

~/update-sqlite.sh

Current installed version: 3.51.2
Latest upstream version: 3.51.2
SQLite is already up to date.

If the source build is older than upstream, the script downloads the new archive, compiles it, installs it under /usr/local, and refreshes the shared library cache with ldconfig.

Test SQLite on Fedora

A quick write test confirms that the sqlite3 shell works and that SQLite can create, populate, and read a database file on your Fedora system.

sqlite3 ~/sqlite-demo.db "CREATE TABLE employees (id INTEGER PRIMARY KEY, name TEXT, role TEXT); INSERT INTO employees (name, role) VALUES ('Ava', 'Admin'), ('Noah', 'Developer'), ('Mia', 'Analyst'); SELECT * FROM employees;"

1|Ava|Admin
2|Noah|Developer
3|Mia|Analyst

The query output confirms SQLite created the database, wrote rows to it, and read them back successfully.

Try a few SQLite shell commands on Fedora

If you want a quick look inside the test database, SQLite’s dot-commands show tables and schema details without writing more SQL. If you open the full interactive shell with sqlite3 ~/sqlite-demo.db, leave it with .quit.

sqlite3 ~/sqlite-demo.db ".tables"
sqlite3 ~/sqlite-demo.db ".schema employees"

employees
CREATE TABLE employees (id INTEGER PRIMARY KEY, name TEXT, role TEXT);

Remove the test database when you are done experimenting with it:

rm -f ~/sqlite-demo.db

Configure SELinux for SQLite Web Apps on Fedora

This section only matters when Apache, Nginx, PHP-FPM, or another web-facing service needs write access to a SQLite database file. If you use SQLite from the terminal or inside local development tools, skip ahead to troubleshooting or removal.

On Fedora, normal file permissions are only part of the story. SELinux can still block writes until the database file has a web-safe context, so use a persistent label instead of a temporary chcon change.

Check SQLite SELinux status on Fedora

sestatus

SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing

If SELinux is disabled or set to permissive mode, you do not need the context changes below. On an enforcing Fedora host, continue with a persistent label.

Assign a persistent SELinux context to the SQLite database

The semanage command comes from policycoreutils-python-utils. Install it first if your Fedora system does not already have it:

sudo dnf install policycoreutils-python-utils

Then apply a persistent writeable context to the database file and restore its label:

sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/testdb.db"
sudo restorecon -v /var/www/html/testdb.db
ls -lZ /var/www/html/testdb.db

Relabeled /var/www/html/testdb.db from unconfined_u:object_r:httpd_sys_content_t:s0 to unconfined_u:object_r:httpd_sys_rw_content_t:s0
-rw-r--r--. 1 root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 0 Mar  6 17:55 /var/www/html/testdb.db

Use httpd_sys_rw_content_t only when the web process must write to the database. If the application only reads from SQLite, use the read-only httpd_sys_content_t label instead. For broader SELinux background, the SELinux on Fedora guide covers mode changes and related administration tasks.

If you still need the web stack itself, set that up first with Apache on Fedora or Nginx on Fedora.

Troubleshoot SQLite on Fedora

Fix “sqlite3: command not found” after a source install

If the source build finishes but the shell still says sqlite3: command not found, check which binary your session can see first.

which sqlite3
echo "$PATH" | tr ':' '\n' | grep '^/usr/local/bin$'

/usr/local/bin/sqlite3
/usr/local/bin

If which sqlite3 returns nothing, the install probably succeeded but your current shell has not picked up /usr/local/bin yet. Open a new terminal window, or reload the path in the current shell:

export PATH="/usr/local/bin:$PATH"
hash -r
/usr/local/bin/sqlite3 --version

If the version command works with the full path, the SQLite build itself is fine and only PATH ordering needed to be refreshed.

Fix “attempt to write a readonly database” in SQLite

This error usually means the directory containing the database is not writable, even when the database file itself looks normal. Web apps can also trigger the same failure when SELinux blocks the write.

Error: stepping, attempt to write a readonly database (8)

Check the directory permissions first, because SQLite needs write access to the folder as well as the database file:

ls -ld /path/to/database-directory
ls -l /path/to/database-directory/app.db

dr-xr-xr-x. 1 joshua joshua 12 Mar  6 17:58 /home/joshua/sqlite-readonly-test
-rw-r--r--. 1 joshua joshua 8192 Mar  6 17:58 /home/joshua/sqlite-readonly-test/app.db

The directory above is read-only, so inserts fail even though the database file itself is present. Give the application owner write access to the directory, then try the write again. For web apps under /var/www, pair the ownership fix with the SELinux labeling steps from the previous section.

chmod 755 /path/to/database-directory
sqlite3 /path/to/database-directory/app.db "INSERT INTO items (name) VALUES ('demo');"

If the insert succeeds without an error, SQLite can write again. When the problem comes from a web server process instead of your own user account, fix the ownership for that service account and reapply the SELinux context.

Remove SQLite from Fedora

Remove the Fedora SQLite package

If you installed SQLite from Fedora’s repositories, remove it with DNF and confirm the RPM is gone.

sudo dnf remove sqlite
rpm -q sqlite

package sqlite is not installed

Remove a source-compiled SQLite build

The next commands remove the source-built SQLite files under /usr/local, your local build directory, and the helper update script. They do not delete any .db files you created elsewhere, so back up and remove those separately if you no longer need them.

sudo rm -f /usr/local/bin/sqlite3
sudo rm -f /usr/local/lib/libsqlite3.*
sudo rm -f /usr/local/lib/pkgconfig/sqlite3.pc
sudo rm -f /usr/local/include/sqlite3.h /usr/local/include/sqlite3ext.h
sudo ldconfig
rm -rf ~/sqlite-source
rm -f ~/update-sqlite.sh

If the Fedora package is still installed, your shell falls back to the repository build as soon as the /usr/local files are gone:

which sqlite3
sqlite3 --version

/usr/bin/sqlite3
3.50.2 2025-06-28 14:00:48 2af157d77fb1304a74176eaee7fbc7c7e932d946bf25325e9c26c91db19ealt1 (64-bit)

Frequently Asked Questions

Conclusion

SQLite is ready on Fedora with the sqlite3 shell available for local databases, quick test fixtures, and lightweight application storage. If you want to build around it next, pair it with Git on Fedora, package it with Docker on Fedora, or move to PostgreSQL on Fedora when you need a concurrent multi-user database server.