How to Install SQLite on Arch Linux

SQLite is a self-contained, serverless database engine that stores everything in a single file. Unlike MySQL or PostgreSQL, SQLite requires no separate server process, making it ideal for embedded applications, local development, and scenarios where a full database server would be overkill. Applications read and write directly to the database file, which simplifies deployment and eliminates network configuration entirely.

This guide covers installing SQLite on Arch Linux, using the command-line shell to create and query databases, installing a graphical database browser for visual editing, and integrating SQLite with shell scripts. By the end, you will have a working SQLite installation with practical knowledge of database creation, querying, and management.

Update Arch Linux

Before installing new packages, synchronize the package database and upgrade all installed packages to ensure compatibility:

sudo pacman -Syu

On a rolling-release distribution, keeping packages synchronized prevents dependency conflicts during installation.

Install SQLite on Arch Linux

Install SQLite from the official Arch Linux core repository:

sudo pacman -S sqlite

This installs the SQLite library, the sqlite3 command-line shell for interactive database work, and development headers for compiling applications that use SQLite.

Verify the installation by checking the SQLite version:

sqlite3 --version

3.51.2 2026-01-09 17:27:48 ...

Install Optional Companion Packages

The SQLite package includes several optional split packages for specific use cases:

Package	Description	Best For
sqlite-doc	HTML documentation and tutorials	Offline reference, learning SQL syntax
sqlite-analyzer	Database space and efficiency analyzer	Database optimization, storage analysis
sqlite-tcl	Tcl programming language bindings	Tcl/Tk application development

Install any optional packages you need:

sudo pacman -S sqlite-doc sqlite-analyzer

The documentation installs to /usr/share/doc/sqlite/, where you can open index.html in a browser for offline access to the complete SQLite documentation.

Use the SQLite Command-Line Shell

The sqlite3 command opens an interactive shell for creating databases, running queries, and managing data. SQLite creates database files on demand when you specify a filename.

Create a Database and Table

Open a new database file by specifying its name:

sqlite3 ~/projects.db

If the file does not exist, SQLite creates it. The shell displays a prompt where you can enter SQL statements:

SQLite version 3.51.2 2026-01-09 17:27:48
Enter ".help" for usage hints.
sqlite>

Create a table to store data:

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

SQLite uses dynamic typing, so column types serve as hints rather than strict constraints. The INTEGER PRIMARY KEY column acts as an auto-incrementing row ID.

Insert and Query Data

Add records to the table:

INSERT INTO tasks (title) VALUES ('Configure backup script');
INSERT INTO tasks (title, status) VALUES ('Update documentation', 'in-progress');
INSERT INTO tasks (title, status) VALUES ('Deploy to production', 'completed');

Query the data to verify insertion:

SELECT * FROM tasks;

1|Configure backup script|pending|2026-02-02 10:15:30
2|Update documentation|in-progress|2026-02-02 10:15:32
3|Deploy to production|completed|2026-02-02 10:15:34

For more readable output, enable column headers and table formatting:

.headers on
.mode column
SELECT * FROM tasks WHERE status != 'completed';

id  title                     status       created_at
--  ------------------------  -----------  -------------------
1   Configure backup script   pending      2026-02-02 10:15:30
2   Update documentation      in-progress  2026-02-02 10:15:32

Useful Shell Commands

SQLite shell commands (dot-commands) control the shell environment and are not SQL statements. They do not require semicolons:

Command	Description
.tables	List all tables in the database
.schema tablename	Show CREATE statement for a table
.headers on	Display column headers in output
.mode column	Format output as aligned columns
.dump	Export entire database as SQL statements
.read filename	Execute SQL from a file
.backup filename	Create a backup copy of the database
.quit or .exit	Exit the SQLite shell

Exit the shell with .quit or press Ctrl+D.

Install DB Browser for SQLite

For visual database management, DB Browser for SQLite provides a graphical interface for creating tables, editing data, and running queries without memorizing SQL syntax. It is available in the official Arch Linux repositories:

sudo pacman -S sqlitebrowser

Launch the application from your application menu or run it from the terminal:

sqlitebrowser &

The & runs the application in the background so you can continue using the terminal. DB Browser lets you open existing databases, browse tables visually, modify records with point-and-click editing, and execute SQL queries with syntax highlighting.

Verify the installation by checking the package information:

pacman -Qi sqlitebrowser | grep -E '^(Name|Version)'

Name            : sqlitebrowser
Version         : 3.13.1-2

DB Browser supports SQLCipher encrypted databases. If you work with encrypted SQLite databases, the Arch package includes SQLCipher support by default.

Use SQLite in Shell Scripts

SQLite integrates well with shell scripts for automation, logging, and data collection tasks. The -cmd flag executes commands before the interactive prompt, and providing SQL directly runs it non-interactively.

Run Queries Non-Interactively

Execute a query and exit immediately:

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

Configure backup script|pending

For machine-readable output in scripts, use CSV mode:

sqlite3 -header -csv ~/projects.db "SELECT * FROM tasks;"

id,title,status,created_at
1,"Configure backup script",pending,"2026-02-02 10:15:30"
2,"Update documentation",in-progress,"2026-02-02 10:15:32"
3,"Deploy to production",completed,"2026-02-02 10:15:34"

Insert Data from Scripts

Create a simple logging script that records events to a SQLite database:

#!/bin/bash
# log-event.sh - Log events to SQLite database

DB_FILE="${HOME}/event_log.db"

# Create table if it doesn't exist
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
);"

# Insert the event
EVENT_TEXT="$1"
HOSTNAME=$(hostname)

sqlite3 "$DB_FILE" "INSERT INTO events (event, hostname) VALUES ('$EVENT_TEXT', '$HOSTNAME');"

echo "Event logged: $EVENT_TEXT"

Save this as log-event.sh, make it executable, and use it to log events:

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

Query the log to see recorded events:

sqlite3 -header -column ~/event_log.db "SELECT * FROM events ORDER BY logged_at DESC LIMIT 5;"

id  event                        hostname    logged_at
--  ---------------------------  ----------  -------------------
2   System update finished       archlinux   2026-02-02 10:30:15
1   Backup completed success...  archlinux   2026-02-02 10:30:10

For production scripts handling untrusted input, use parameterized queries through a proper SQLite binding (Python, PHP, etc.) to prevent SQL injection. The shell example above is safe only for controlled, trusted input.

Enable Write-Ahead Logging

By default, SQLite uses rollback journal mode, which locks the entire database during writes. For applications with concurrent readers and writers, Write-Ahead Logging (WAL) mode allows reads to continue while writes are in progress:

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

wal

WAL mode creates additional files (database-wal and database-shm) alongside your database. These files are part of the database state, so include them in backups. The mode persists across connections, so you only need to set it once per database.

WAL mode improves concurrency but requires that the database file, WAL file, and shared-memory file all reside on the same filesystem. Network filesystems like NFS do not support the necessary locking mechanisms for WAL mode.

Troubleshoot Common Issues

Database Is Locked

The error “database is locked” occurs when another process holds a write lock on the database:

Error: database is locked

To diagnose, check for processes accessing the database:

fuser ~/projects.db

If another application holds the lock, either wait for it to complete or close that application. For scripts that may conflict, use WAL mode to allow concurrent reads, or implement retry logic with a timeout:

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

The .timeout 5000 command waits up to 5 seconds (5000 milliseconds) for the lock to become available before failing.

Corrupt Database Recovery

If a database becomes corrupted (usually from system crashes or disk failures during writes), attempt recovery by dumping and recreating:

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

The .recover command attempts to extract all readable data from a damaged database. If .recover fails, try the older .dump command, which may succeed for less severe corruption:

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

Verify the recovered database integrity:

sqlite3 ~/recovered.db "PRAGMA integrity_check;"

ok

Permission Denied on Database File

SQLite requires write permission on both the database file and its directory (for creating journal and WAL files). If you see permission errors:

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

Check file and directory permissions:

ls -la ~/projects.db
ls -la ~/

Fix ownership if the database was created by a different user or as root:

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

Slow Performance on Btrfs

Arch Linux users commonly install on Btrfs, which enables Copy-on-Write (COW) by default. For database files that receive frequent small writes, COW can cause severe fragmentation and degrade performance over time. The database file fragments because Btrfs copies and rewrites blocks rather than updating them in place.

Disable COW on individual database files:

chattr +C ~/projects.db

For new databases, set the attribute on the parent directory before creating the database file:

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

Verify the attribute is set:

lsattr ~/projects.db

---------------C------- /home/user/projects.db

The C in the output confirms COW is disabled for that file. This attribute only affects new data written after setting it, so apply it before the database grows large.

Remove SQLite

The core sqlite package is a dependency of essential system packages including gnupg and util-linux-libs, so it cannot be removed without breaking your system. However, you can remove the optional companion packages you installed:

sudo pacman -Rns sqlite-doc sqlite-analyzer sqlitebrowser

The -Rns flags remove the packages (-R), unneeded dependencies (-s), and backup configuration files (-n). Omit any packages you did not install.

Your database files (.db) remain untouched by package removal. Delete them manually if no longer needed, or keep them for use with other SQLite tools or on other systems.

Verify the optional packages are removed:

pacman -Qi sqlitebrowser

error: package 'sqlitebrowser' was not found

Frequently Asked Questions

Conclusion

You now have SQLite installed on Arch Linux with the command-line tools for database management, optional packages for documentation and analysis, and a graphical browser for visual editing. SQLite works well for local applications, development databases, and shell script automation where a full database server would add unnecessary complexity. For applications requiring network access, concurrent writes from multiple clients, or advanced features like replication, see the MariaDB installation guide or PostgreSQL installation guide for Arch Linux. The Arch Wiki SQLite page and SQLite official documentation cover additional topics including full-text search, JSON support, and language bindings.