sqlite3: Usage, Options & Common CI Errors
sqlite3 runs SQL against a file-backed SQLite database from the shell.
sqlite3 is the zero-server database CI uses for fast, isolated test fixtures. The defining failure is "database is locked", which comes from concurrent writers or an open transaction.
What it does
sqlite3 opens a SQLite database file (or :memory:) and runs SQL interactively, from a -cmd/argument, or from a .read script. There is no server - the database is a single file the process opens directly.
Common usage
sqlite3 app.db 'SELECT count(*) FROM users;'
sqlite3 app.db < schema.sql
sqlite3 app.db '.read seed.sql'
sqlite3 -batch app.db 'PRAGMA journal_mode=WAL;'
sqlite3 app.db '.mode csv' '.import data.csv users'Options
| Item | What it does |
|---|---|
| <file> "SQL" | Open the file and run the statement |
| .read <file> | Execute SQL from a file |
| .mode csv|column|json | Set output/import format |
| .import <file> <table> | Bulk-load a file into a table |
| .dump | Emit SQL to recreate the database |
| -batch / -cmd | Non-interactive / run a command first |
Common errors in CI
Error: database is locked - another process (or a leftover connection) holds a write lock; close other writers, set a busy timeout (sqlite3 -cmd ".timeout 5000"), or use PRAGMA journal_mode=WAL so readers and a writer coexist. "Error: no such table" usually means the schema script did not run or you opened the wrong file path. Passing a missing file path silently creates an empty database, which then fails later with "no such table" - verify the file exists first.