sqlite3: Run Queries Against a SQLite File
sqlite3 db.sqlite "SELECT 1" runs SQL against a file-based database with no server to start.
SQLite has no daemon, so the sqlite3 CLI opens a database file directly. That makes it ideal for CI: no readiness wait, no network. You run SQL inline or use dot-commands like .tables and .schema to inspect it.
What it does
sqlite3 opens (or creates) a database file and runs SQL against it. A statement passed as the second argument runs and exits; with no statement it opens an interactive shell. Dot-commands (.tables, .schema, .dump) are client features that inspect or export the database.
Common usage
# list tables and view schema
sqlite3 app.db ".tables"
sqlite3 app.db ".schema users"
# run a query
sqlite3 app.db "SELECT count(*) FROM users"
# create/apply a schema from a file
sqlite3 app.db < schema.sqlOptions
| Command / flag | What it does |
|---|---|
| .tables | List tables in the database |
| .schema [table] | Print CREATE statements (all, or one table) |
| .dump | Export the whole database as SQL |
| .import <file> <table> | Load a CSV/TSV file into a table |
| -csv / -header | CSV output / include column headers |
| -cmd "<dot>" | Run a dot-command before the SQL argument |
In CI
SQLite needs no service container or readiness check; just make sure the file path is writable by the job. Opening a non-existent file silently creates an empty database, which is why a "no such table" error usually means the migration ran against the wrong path, not that it failed. Use an absolute path to avoid working-directory surprises.
Common errors in CI
"Error: no such table: users" almost always means sqlite3 opened a different (or freshly created empty) file than the migration wrote to; check the path. "Error: near \"...\" : syntax error" points at the offending SQL. "Error: database is locked" happens when another process holds a write lock; SQLite allows only one writer at a time. "unable to open database file" means a missing directory or no write permission.