A MySQL or Postgres database lives in a server process you install, start and log in to over the network. SQLite's whole database is one ordinary file on disk, and the docs put it best: SQLite competes with fopen(). No daemon, no port, no password.

That's why it's everywhere. The sqlite.org pages say it's found in every Android device, every iPhone, every Mac, every Windows 10/11 install and every major browser, more than all other database engines combined. You have been carrying these files for years.

To read one you don't set up a server. You open the file.

Two languages share the sqlite> prompt. Lines that start with a dot are intercepted by the sqlite3 program itself. Lines that don't go to the SQLite library as SQL.

Dot-commands have their own rules: they must start at the left margin, sit on one line, and they take no semicolon. There are over 60 of them. They're shell settings and shortcuts, which is why they'd never work inside sqlite3_exec() in your code.

SQL ends in a semicolon. Dot-commands are one line, no semicolon, no indent. That's the whole split.

.import --csv data.csv tab1 reads the file into the table. The parsing follows RFC 4180, so quoted fields with commas inside come through correctly. The source can even be a command: start it with | and its output becomes the input.

Set the mode or pass --csv explicitly; without it the delimiters in force for the current output mode are used, and that's how a csv file lands mangled. The exact example from the docs, with headers skipped, is next page.

This one command is the answer to the internet's most-asked sqlite question.

The docs' export is three lines. .mode csv --titles on, so the first row carries column labels, .once dataout.csv, then the query. Output is CSV per RFC 4180, quoting and all, so it opens clean anywhere.

Any query exports, not just a whole table: add WHERE and you've exported a slice. When it's done, .mode box brings the screen back to human shape.

Import on page 13, export here. Round-tripping CSV is most of what people do with this shell.

.dump renders the whole database as one UTF-8 text file of pure SQL. Pipe it back into sqlite3 and you have the database again, on this machine or another.

The docs' archival recipe, verbatim: sqlite3 ex1 .dump | gzip -c >ex1.dump.gz, rebuilt with zcat ex1.dump.gz | sqlite3 ex2. And because the format is pure SQL, the same stream feeds other SQL engines.

A backup you can read with your eyes and restore with a pipe. That's .dump.

Point sqlite3 at a file you must not change and read mode matters. .open --readonly ex1.db opens it with writes prohibited, and sqlite3 -readonly ex1.db does it from launch.

Pair it with --ifexists, which refuses to open a file that isn't there, the opposite of page 2's auto-create. On a file that matters, that pair removes both ways to damage it by accident.

An empty ex1.db sitting sadly next to a typo'd ex1d.db is the memorial of a missing --ifexists.