How to Install SQLite on Arch Linux

SQLite on Arch Linux installs from the official repositories as the sqlite package, which provides the sqlite3 command-line shell, shared library, and development headers. The setup is lightweight because SQLite stores each database in a regular file instead of running a separate database server.

Arch users commonly need SQLite for local application data, development databases, embedded tools, scripts, and single-user projects. DB Browser for SQLite is available separately as sqlitebrowser when a graphical editor is more practical than the command-line shell.

Install SQLite on Arch Linux

Update Arch Linux Before Installing SQLite

Synchronize the package database and upgrade installed packages before adding SQLite:

sudo pacman -Syu

Arch is a rolling-release distribution, so partial upgrades can create dependency conflicts. Use the full system update before installing or refreshing repository packages.

If your user account cannot run sudo, configure sudo access first. The Arch Linux sudo users guide covers the required group and privilege setup.

Install the SQLite Package

Install SQLite from the Arch core repository:

sudo pacman -S sqlite

The package name is sqlite, while the terminal command is sqlite3. Pacman installs the SQLite shell, the libsqlite3 shared library, and headers such as sqlite3.h for software that builds against SQLite.

Verify SQLite Package Ownership

Confirm that the sqlite3 binary is present and owned by the repository package:

command -v sqlite3
pacman -Qo /usr/bin/sqlite3

/usr/bin/sqlite3
/usr/bin/sqlite3 is owned by sqlite 3.53.1-1

Check the installed SQLite upstream version:

sqlite3 --version | cut -d' ' -f1

3.53.1

Arch package versions change quickly on the rolling branch, so a newer version number is normal after future syncs.

Install Optional SQLite Companion Packages

Arch splits several SQLite-related tools into optional packages:

Package	Purpose	Common Use
`sqlite-doc`	Offline HTML documentation	Local reference for SQL syntax, pragmas, and SQLite features
`sqlite-analyzer`	Database file analysis tool	Inspecting table, index, and page-size usage with `sqlite3_analyzer`
`sqlite-tcl`	Tcl bindings	Using SQLite from Tcl or Tcl/Tk applications

Install only the companion packages you need:

sudo pacman -S sqlite-doc sqlite-analyzer

The documentation package installs files under /usr/share/doc/sqlite/. The analyzer package adds the sqlite3_analyzer command for storage and index-efficiency checks.

Install DB Browser for SQLite on Arch Linux

Install DB Browser for SQLite on Arch Linux with the official sqlitebrowser package from the Arch extra repository:

sudo pacman -S sqlitebrowser

Verify the package and launcher path:

pacman -Q sqlitebrowser
command -v sqlitebrowser

sqlitebrowser 3.13.1-3
/usr/bin/sqlitebrowser

Launch it from the desktop application menu or from a terminal:

sqlitebrowser

DB Browser provides visual table browsing, data editing, SQL query tabs, import and export tools, and SQLCipher support through the Arch package dependency set. Use it when you need a SQLite viewer, a graphical table editor, or a DB Browser workflow instead of the sqlite3 shell.

Use the SQLite Command-Line Shell on Arch Linux

The SQLite command-line shell creates databases, runs SQL statements, changes output modes, imports data, and performs backups through sqlite3. A database file is created when you open a path that does not already exist.

Create a Database and Table

Open a new database file:

sqlite3 ~/projects.db

sqlite>

Create a table for local task data:

CREATE TABLE tasks (
    id INTEGER PRIMARY KEY,
    title TEXT NOT NULL,
    status TEXT DEFAULT 'pending',
    created_at TEXT DEFAULT CURRENT_TIMESTAMP
);

The INTEGER PRIMARY KEY column acts as the row identifier. SQLite column types define affinity rather than the strict typing model used by some server databases.

Insert and Query Data

Add a few rows:

INSERT INTO tasks (title, status, created_at) VALUES ('Configure backup script', 'pending', '2026-05-08 09:00:00');
INSERT INTO tasks (title, status, created_at) VALUES ('Update documentation', 'in-progress', '2026-05-08 09:05:00');
INSERT INTO tasks (title, status, created_at) VALUES ('Deploy to production', 'completed', '2026-05-08 09:10:00');

Query the table:

SELECT * FROM tasks;

1|Configure backup script|pending|2026-05-08 09:00:00
2|Update documentation|in-progress|2026-05-08 09:05:00
3|Deploy to production|completed|2026-05-08 09:10:00

Enable headers and table formatting for readable terminal output:

.headers on
.mode table
SELECT id, title, status FROM tasks WHERE status != 'completed';

+----+-------------------------+-------------+
| id |          title          |   status    |
+----+-------------------------+-------------+
|  1 | Configure backup script | pending     |
|  2 | Update documentation    | in-progress |
+----+-------------------------+-------------+

Useful SQLite Shell Commands

SQLite dot-commands control the shell environment and do not use SQL semicolons:

Command	Purpose
`.tables`	List tables in the current database
`.schema tasks`	Show the table definition for `tasks`
`.headers on`	Display column names in query output
`.mode table`	Format query output as an ASCII table
`.mode csv`	Format query output as CSV
`.dump`	Export the database as SQL statements
`.read file.sql`	Run SQL statements from a file
`.backup backup.db`	Create a consistent database backup
`.quit`	Exit the SQLite shell

Press Ctrl+D or run .quit to close the shell.

Back Up SQLite Databases on Arch Linux

The SQLite shell can create a consistent copy of a database while respecting SQLite locking behavior:

sqlite3 ~/projects.db ".backup ~/projects-backup.db"

Verify the backup before relying on it:

sqlite3 ~/projects-backup.db "PRAGMA integrity_check;"

ok

A SQL dump is useful when you want a portable text representation of the schema and data:

sqlite3 ~/projects.db ".dump" > ~/projects-backup.sql

When copying files directly, include the database file and any matching -wal and -shm files if WAL mode is active. The .backup command is usually safer because it asks SQLite to produce a consistent backup for you.

Enable SQLite WAL Mode on Arch Linux

Write-Ahead Logging (WAL) allows readers to continue while a writer commits changes, which can help local applications and scripts that read from the same database during writes:

sqlite3 ~/projects.db "PRAGMA journal_mode=WAL;"

wal

WAL mode persists per database after it is enabled. Keep the database, WAL file, and shared-memory file on the same local filesystem; network filesystems such as NFS do not provide the locking behavior WAL depends on.

Choose SQLite or Server Databases on Arch Linux

SQLite is usually the right choice for embedded applications, desktop tools, local caches, small web projects, test databases, and scripts that need a reliable file-backed store. It avoids service management, port exposure, authentication setup, and network configuration.

Use MariaDB on Arch Linux or PostgreSQL on Arch Linux when the database needs network clients, centralized access control, replication, many concurrent writers, or server-side administration features. SQLite supports multiple readers, but write concurrency remains more limited than a dedicated database server.

SQLite’s official limits documentation covers theoretical maximums, but practical limits depend on schema design, indexes, storage performance, and write patterns. For high-volume multi-user workloads, benchmark with real data before choosing SQLite as the permanent storage layer.

Use SQLite in Arch Linux Shell Scripts

Run Queries Non-Interactively

Run a query and exit immediately:

sqlite3 ~/projects.db "SELECT title, status FROM tasks WHERE status = 'pending';"

Configure backup script|pending

Use CSV output with headers for script-friendly exports:

sqlite3 -csv -header ~/projects.db "SELECT id, title, status FROM tasks;"

id,title,status
1,"Configure backup script",pending
2,"Update documentation",in-progress
3,"Deploy to production",completed

Insert Data from Scripts

A small Bash logger can store local events in a SQLite database:

#!/usr/bin/env bash
set -euo pipefail

DB_FILE="${HOME}/event_log.db"
EVENT_TEXT="${1:?Usage: log-event.sh MESSAGE}"
HOST_NAME="${HOSTNAME:-$(cat /etc/hostname 2>/dev/null || printf 'localhost')}"

EVENT_SQL=$(printf '%s' "$EVENT_TEXT" | sed "s/'/''/g")
HOST_SQL=$(printf '%s' "$HOST_NAME" | sed "s/'/''/g")

sqlite3 "$DB_FILE" "CREATE TABLE IF NOT EXISTS events (
    id INTEGER PRIMARY KEY,
    event TEXT NOT NULL,
    hostname TEXT,
    logged_at TEXT DEFAULT CURRENT_TIMESTAMP
);"

sqlite3 "$DB_FILE" "INSERT INTO events (event, hostname) VALUES ('$EVENT_SQL', '$HOST_SQL');"

printf 'Event logged: %s\n' "$EVENT_TEXT"

Save the script as log-event.sh, then make it executable with chmod:

chmod +x log-event.sh
./log-event.sh "Backup completed successfully"
./log-event.sh "System update finished"

Event logged: Backup completed successfully
Event logged: System update finished

Query the recent log entries:

sqlite3 -header -column ~/event_log.db "SELECT id, event, hostname FROM events ORDER BY id;"

id  event                          hostname
--  -----------------------------  ---------
 1  Backup completed successfully  archlinux
 2  System update finished         archlinux

Shell escaping is enough for this simple local logging example, but application code that accepts untrusted input should use a SQLite library with parameterized queries instead of composing SQL strings manually.

Troubleshoot SQLite on Arch Linux

Fix a Database Is Locked Error

A locked database error means another connection is holding a write lock:

Error: database is locked

Use fuser from the psmisc package to find processes using the database file:

sudo pacman -S psmisc
fuser ~/projects.db

Wait for the writer to finish, close the application that owns the lock, or add a timeout for scripts that may briefly collide with another process:

sqlite3 ~/projects.db ".timeout 5000" "UPDATE tasks SET status = 'completed' WHERE id = 1;"

The timeout value is measured in milliseconds, so 5000 waits up to five seconds before SQLite returns a lock failure.

Recover a Corrupt Database

Try SQLite’s recovery command first when a damaged database can still be opened:

sqlite3 ~/corrupted.db ".recover" | sqlite3 ~/recovered.db

If recovery fails, an older SQL dump may still extract readable schema and rows:

sqlite3 ~/corrupted.db ".dump" | sqlite3 ~/recovered.db

Check the recovered database:

sqlite3 ~/recovered.db "PRAGMA integrity_check;"

ok

Fix Permission Denied on a Database File

SQLite needs write permission on the database file and the directory that contains it, because journal and WAL files are created next to the database:

Error: unable to open database "projects.db": unable to open database file

Inspect the file and parent directory:

ls -l ~/projects.db
ls -ld ~

Restore ownership if the database was accidentally created as root:

sudo chown "$USER:$USER" ~/projects.db

Reduce Btrfs Copy-on-Write Overhead

On Btrfs systems, frequently written database files can suffer from fragmentation because Copy-on-Write rewrites blocks instead of updating them in place. Disable COW on an empty database directory before creating new SQLite databases there:

mkdir -p ~/databases
chattr +C ~/databases
lsattr -d ~/databases

---------------C------- /home/user/databases

The C attribute is not retroactive for data already written to an existing file. For an existing database, back it up into the NOCOW directory and verify the copy:

sqlite3 ~/projects.db ".backup ~/databases/projects.db"
sqlite3 ~/databases/projects.db "PRAGMA integrity_check;"

ok

Update or Remove SQLite on Arch Linux

Update SQLite

SQLite is updated through the normal Arch system upgrade process:

sudo pacman -Syu

This updates sqlite, optional SQLite companion packages, DB Browser for SQLite, and the rest of the synchronized package set when newer repository builds are available.

Remove Optional SQLite Packages

Remove optional packages you no longer use:

sudo pacman -Rns sqlite-doc sqlite-analyzer sqlite-tcl sqlitebrowser

Omit any package that was not installed. Database files such as .db, .sqlite, and .sqlite3 are user data, so Pacman does not remove them.

Verify optional package removal:

pacman -Q sqlite-doc sqlite-analyzer sqlite-tcl sqlitebrowser

error: package 'sqlite-doc' was not found
error: package 'sqlite-analyzer' was not found
error: package 'sqlite-tcl' was not found
error: package 'sqlitebrowser' was not found

Check Before Removing the Core SQLite Package

Many Arch systems keep sqlite because other packages depend on the SQLite library. Check reverse dependencies before considering removal:

pacman -Qi sqlite

Required By     : gnupg  util-linux-libs
Optional For    : None

Your dependency list may include additional packages depending on what is installed. If Required By lists packages, leave sqlite installed. Do not force removal with dependency-skipping flags such as -Rdd, because that can break package management, security tooling, desktop components, or applications linked against libsqlite3.

Conclusion

SQLite is available on Arch through the official sqlite package, with sqlite3 ready for local databases, backups, WAL tuning, and script-friendly queries. DB Browser for SQLite adds a visual editor through sqlitebrowser, while MariaDB or PostgreSQL remain better fits when the database needs a server, network clients, or heavier concurrent writes. The Arch Wiki SQLite page and SQLite documentation cover advanced features such as full-text search, JSON, pragmas, and limits.