How to Install SQLite on Fedora 44

SQLite is often the fastest way to give a script, test fixture, or small local app a real SQL database without running a separate server. To install SQLite on Fedora, use the sqlite RPM from Fedora’s repositories; that package provides the sqlite3 command-line shell.

The Fedora package is the low-maintenance default, while a source build under /usr/local is useful when you need the newest upstream CLI or library before it reaches Fedora updates. The source path downloads the official SQLite autoconf tarball from sqlite.org and verifies its published SHA3-256 checksum before compiling.

Install SQLite on Fedora

Fedora’s repository method should be the starting point for most systems. Use the source method only when an application, test suite, or development workflow needs a newer upstream release than Fedora currently ships.

Method	Source	Version Track	Updates	Best For
Fedora package	Fedora repositories	Fedora-tested stable release	Normal Fedora package upgrades	Most users who want simple maintenance
Source build	SQLite upstream	Newest upstream release	Manual rebuild or helper script	Developers who need the latest CLI or library immediately

Pick one active SQLite command unless you deliberately want both. The Fedora package installs /usr/bin/sqlite3, while the source method installs /usr/local/bin/sqlite3. On a default Fedora shell, /usr/local/bin usually wins on PATH, so verify the active binary with command -v sqlite3 after mixing methods.

Install SQLite from Fedora’s Repositories

On Fedora, the package name is sqlite, even though the command you run afterward is sqlite3. A command such as sudo dnf install sqlite3 fails because Fedora does not publish a separate sqlite3 package.

Refresh Fedora package metadata and apply available package updates before installing SQLite:

sudo dnf upgrade --refresh

Commands that install or remove system packages need sudo. If your account does not have sudo access yet, follow the guide on how to add a user to sudoers on Fedora before continuing.

Install SQLite from Fedora’s repositories:

sudo dnf install sqlite

Confirm that the RPM is installed, the shell command resolves through /usr/bin, and SQLite can print its version. Package release strings can vary by Fedora release and normal updates, but the relevant output should look like this:

rpm -q sqlite
command -v sqlite3
sqlite3 --version

sqlite-3.51.2-1.fc44.x86_64
/usr/bin/sqlite3
3.51.2 2026-01-09 17:27:48 b270f8339eb13b504d0b2ba154ebca966b7dde08e40c3ed7d559749818cbalt1 (64-bit)

The dnf info sqlite3 check returns No matching packages to list, which confirms the package-name boundary when older examples or copied commands point at sqlite3.

Install Optional SQLite Development Files

Most readers only need the sqlite package. Install sqlite-devel when a C or C++ project, build system, or pkg-config check needs SQLite headers and library metadata from Fedora’s package set:

sudo dnf install sqlite-devel

Confirm that Fedora installed the development RPM and its main header and pkg-config files:

rpm -q sqlite-devel
rpm -ql sqlite-devel | grep -E '/sqlite3\.h$|/pkgconfig/sqlite3\.pc$'

sqlite-devel-3.51.2-1.fc44.x86_64
/usr/include/sqlite3.h
/usr/lib64/pkgconfig/sqlite3.pc

Compile the Latest SQLite Source on Fedora

The source method installs SQLite under /usr/local. Fedora’s packaged files remain under /usr, so removing the source build later can return the system to the repository version. SQLite also publishes precompiled Linux tools, but the source archive is the better Fedora path when you need both the CLI and library under a controlled prefix.

Install SQLite Build Tools on Fedora

Install the compiler, build utilities, download tools, archive tools, and OpenSSL checksum support needed for the source workflow:

sudo dnf install gcc make curl tar openssl

SQLite’s compile notes describe the Unix build as a standard ./configure and make workflow. The autoconf bundle also includes the amalgamation source and a generated configure script, so no third-party library dependency is required for the standard shell build.

Download and Verify the SQLite Source Archive

Create a working directory, read the current SQLite autoconf release metadata from the official download page, and verify the downloaded archive against the published SHA3-256 checksum. The workflow uses curl in Linux for the download request.

(
set -euo pipefail

mkdir -p ~/sqlite-source
cd ~/sqlite-source || exit

DOWNLOAD_PAGE=$(mktemp)
curl -fsSL https://www.sqlite.org/download.html -o "$DOWNLOAD_PAGE"

read -r _ SQLITE_TARBALL SQLITE_SHA3 < <(
  awk -F, '/^PRODUCT,/ && $3 ~ /sqlite-autoconf-[0-9]+\.tar\.gz/ {print $2, $3, $5; exit}' "$DOWNLOAD_PAGE"
)

if [[ -z "${SQLITE_TARBALL:-}" || -z "${SQLITE_SHA3:-}" ]]; then
  echo "Could not detect SQLite source metadata from sqlite.org."
  rm -f "$DOWNLOAD_PAGE"
  exit 1
fi

SQLITE_ARCHIVE=${SQLITE_TARBALL##*/}
curl -fsSLO "https://www.sqlite.org/$SQLITE_TARBALL"

ACTUAL_SHA3=$(openssl dgst -sha3-256 -r "$SQLITE_ARCHIVE" | awk '{print $1}')
if [[ "$ACTUAL_SHA3" != "$SQLITE_SHA3" ]]; then
  echo "SQLite archive checksum verification failed."
  rm -f "$DOWNLOAD_PAGE"
  exit 1
fi

echo "Verified $SQLITE_ARCHIVE with SHA3-256."
tar -xzf "$SQLITE_ARCHIVE"
rm -f "$DOWNLOAD_PAGE"
)

A successful checksum check prints the archive name it verified:

Verified sqlite-autoconf-3530100.tar.gz with SHA3-256.

SQLite encodes release numbers in archive filenames. For example, SQLite 3.53.1 downloads as sqlite-autoconf-3530100.tar.gz, where the trailing 00 is part of SQLite’s upstream numbering format. The guide to opening .gz and .tgz files in Linux explains the archive format if you want more background on the tar -xzf step.

Configure, Compile, and Install the SQLite Source Build

Build the extracted source and install it under /usr/local:

(
set -euo pipefail

SQLITE_SOURCE_DIR=$(find ~/sqlite-source -maxdepth 1 -type d -name 'sqlite-autoconf-*' | sort -V | tail -n 1)
if [[ -z "${SQLITE_SOURCE_DIR:-}" ]]; then
  echo "Could not locate the extracted SQLite source directory."
  exit 1
fi

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 build is first in your shell path. A current upstream build prints the version you just compiled, so the exact number changes as SQLite releases newer sources:

command -v sqlite3
sqlite3 --version

/usr/local/bin/sqlite3
3.53.1 2026-05-05 10:34:17 c88b22011a54b4f6fbd149e9f8e4de77658ce58143a1af0e3785e4e6475127e9 (64-bit)

If the Fedora package is also installed, the packaged binary remains available at /usr/bin/sqlite3. Removing the source build drops the default shell command back to Fedora’s packaged version.

Test SQLite on Fedora

A quick write test confirms that the sqlite3 shell 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 rows confirm that SQLite created the database, wrote records to it, and read them back successfully.

Inspect the SQLite Test Database on Fedora

SQLite dot-commands show tables and schema details without writing more SQL. If you open the 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

Run these SELinux commands only 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, you do not need them.

On Fedora, normal file permissions are only part of the write path. SELinux can still block a web process until the database file has a suitable context, so use a persistent semanage fcontext rule instead of a temporary chcon label.

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 permissive, the context change is not required for enforcement. 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

Create the database file if the application has not created it yet, then give the file to the service account that writes to it. Set APP_USER to an existing account from your web stack; the example uses apache, which Fedora web packages commonly use for Apache HTTP Server and PHP-FPM.

APP_USER=apache

if getent passwd "$APP_USER" >/dev/null; then
  sudo mkdir -p /var/www/html
  sudo touch /var/www/html/app.db
  sudo chown "$APP_USER:$APP_USER" /var/www/html/app.db
  sudo chmod 664 /var/www/html/app.db
  sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/app\.db"
  sudo restorecon -v /var/www/html/app.db
else
  printf 'Set APP_USER to an existing service account before continuing.\n' >&2
fi

Confirm the new SELinux context. The important field is the httpd_sys_rw_content_t type:

ls -Z /var/www/html/app.db

unconfined_u:object_r:httpd_sys_rw_content_t:s0 /var/www/html/app.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 mode background, the Fedora SELinux status and mode guide covers enforcing, permissive, disabled, and re-enabled states.

If the web stack itself is not ready yet, set that up first with Apache on Fedora, Nginx on Fedora, or Nginx with PHP-FPM on Fedora.

Remove the SQLite SELinux Context Later

If the database moves, the app no longer needs web-write access, or you used a temporary test path, remove the article-created context rule and restore Fedora’s default label:

sudo semanage fcontext -d "/var/www/html/app\.db"
sudo restorecon -v /var/www/html/app.db

Update SQLite on Fedora

Update the Fedora SQLite Package

The repository method updates with normal Fedora package upgrades. This keeps SQLite on the Fedora-tested branch for your release:

sudo dnf upgrade --refresh sqlite

Update a Source-Compiled SQLite Build

If you choose the source method, keep a small update helper in your home directory so you can repeat the release lookup, checksum verification, build, and install steps safely.

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

for cmd in awk curl gcc make openssl tar; do
  if ! command -v "$cmd" >/dev/null; then
    echo "Missing required command: $cmd"
    echo "Install it with: sudo dnf install gcc make curl tar openssl"
    exit 1
  fi
done

DOWNLOAD_PAGE=$(mktemp)
BUILD_DIR=""

cleanup() {
  rm -f "$DOWNLOAD_PAGE"
  if [[ -n "${BUILD_DIR:-}" ]]; then
    rm -rf "$BUILD_DIR"
  fi
}
trap cleanup EXIT

curl -fsSL https://www.sqlite.org/download.html -o "$DOWNLOAD_PAGE"
read -r LATEST_VERSION LATEST_TARBALL LATEST_SHA3 < <(
  awk -F, '/^PRODUCT,/ && $3 ~ /sqlite-autoconf-[0-9]+\.tar\.gz/ {print $2, $3, $5; exit}' "$DOWNLOAD_PAGE"
)

if [[ -z "${LATEST_VERSION:-}" || -z "${LATEST_TARBALL:-}" || -z "${LATEST_SHA3:-}" ]]; then
  echo "Could not detect the latest SQLite source metadata from sqlite.org."
  exit 1
fi

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)
cd "$BUILD_DIR"

ARCHIVE_NAME=${LATEST_TARBALL##*/}
echo "Downloading SQLite $LATEST_VERSION..."
curl -fsSLO "https://www.sqlite.org/$LATEST_TARBALL"

ACTUAL_SHA3=$(openssl dgst -sha3-256 -r "$ARCHIVE_NAME" | awk '{print $1}')
if [[ "$ACTUAL_SHA3" != "$LATEST_SHA3" ]]; then
  echo "SQLite archive checksum verification failed."
  exit 1
fi
echo "Verified SHA3-256 checksum."

tar -xzf "$ARCHIVE_NAME"
BUILD_SOURCE_DIR=$(find "$BUILD_DIR" -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"
./configure --prefix=/usr/local
make -j"$(nproc)"
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 helper whenever you want to check for a newer upstream source release:

~/update-sqlite.sh

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

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

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 current session can see first.

command -v sqlite3
printf '%s\n' "$PATH" | tr ':' '\n' | grep -Fx '/usr/local/bin'

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

If command -v sqlite3 returns nothing, the build may be installed but your current shell has not picked up /usr/local/bin. 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 in this example is read-only, so inserts fail even though the database file exists. Give the application owner write access to the directory, then try the write again. Replace appuser with the account that runs your script or web application. For web apps under /var/www, pair the ownership fix with the SELinux labeling steps from the previous section.

sudo chown appuser:appuser /path/to/database-directory /path/to/database-directory/app.db
sudo chmod u+rwx /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 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 the main RPM and the optional development package when present:

sudo dnf remove sqlite sqlite-devel

Confirm the packages are no longer installed:

rpm -q sqlite sqlite-devel

package sqlite is not installed
package sqlite-devel 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 rm -f /usr/local/share/man/man1/sqlite3.1
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. Example output looks like this:

hash -r
command -v sqlite3
sqlite3 --version

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

Conclusion

SQLite is ready on Fedora through the sqlite3 shell, with the repository package covering low-maintenance systems and the verified source build available for newer upstream releases. From here, Git on Fedora fits version-controlled database fixtures, while Docker on Fedora helps package apps that use SQLite during development.