Install and open SQLite

Start by checking whether the SQLite shell is already available:

sqlite3 --version
# 3.43.2 2023-10-10 13:08:14 4310099cce5a487035fa535dd3002c59ac7f1d1bec68d7cf317fd3e769484790

The first number is what matters. Anything reasonably recent works for this course; you’ll want 3.37 or newer later for STRICT tables.

macOS includes a system copy. On macOS you can also install a newer copy with brew install sqlite — note that Homebrew installs it keg-only, so the system sqlite3 stays first on your PATH unless you use the full Homebrew path. On Windows or Linux, use the package linked from the official SQLite download page or your operating system’s package manager. On Debian or Ubuntu that’s:

sudo apt install sqlite3

There is nothing else to install. No service to start, no port to open, no user account to create. The sqlite3 binary is the entire toolchain.

Open your first database

Now open a database named notes.db:

sqlite3 notes.db

You should see a sqlite> prompt:

SQLite version 3.43.2 2023-10-10 13:08:14
Enter ".help" for usage hints.
sqlite>

Run SELECT sqlite_version(); to check the library used by this shell, then leave with .quit.

That version check matters more than it looks. The sqlite3 shell and the SQLite library linked into your application (Node, Python, an ORM) can be different versions with different feature support. When something works in the shell but fails in your app, compare versions first.

A quiet gotcha

If you run ls after quitting, you may find no notes.db file at all. That’s expected: SQLite delays creating the file until you write a schema or data to it. Opening alone isn’t enough. The next lesson uses that behavior to create the real file.

The flip side bites more often: sqlite3 never complains about a wrong path. Mistype sqlite3 notse.db and you get a fresh empty database instead of an error. If a database you know has tables suddenly looks empty, check which file you actually opened before assuming data loss.