What SQLite Actually Is — No Server, Just a File

This course, like postgres1, assumes real SQL knowledge already covered by mysql2/mysql3 and won't re-teach SELECT, JOINs, or query fundamentals. But SQLite's own real differentiator runs deeper than Postgres's did — it isn't a client-server database with a different feature set. It isn't a server at all.

Client-Server vs. Embedded — A Fundamentally Different Model

MySQL and Postgres are both client-server systems: a separate server process runs continuously, listening on a network port, and applications connect to it as a separate, independent process — even on the same machine, the database and the application are two different running programs communicating over a socket. This is exactly what mysql1 and postgres1-2 both walked through: install and start a server, then connect a client to it.

SQLite has no server process at all. SQLite is a C library, linked directly into the application's own process. When application code "talks to" SQLite, it isn't sending anything over a network or even a local socket — it's making ordinary in-process function calls to library code running in the exact same process as the application itself.

A real, concrete consequence: there's no "SQLite server" to install, start, stop, or crash independently. If the application process ends, database access ends with it — though the data itself persists safely on disk — and there's no separate service whose uptime needs monitoring at all.

A "Database" Is Just a File

In SQLite, the entire database — schema, tables, indexes, all data — lives in a single ordinary file on disk (commonly given a .db, .sqlite, or .sqlite3 extension, though the extension itself means nothing to SQLite). Opening a database is as simple as opening that file.

In MySQL or Postgres, a "database" is a logical construct managed by a running server process, spread across the server's own internal storage structures (and, per postgres1-2, potentially spanning multiple schemas) — copying or backing up a database means using the server's own dump/export tooling. In SQLite, copying the database is literally copying the file:

cp mydata.db backup.db

That single command is a complete, valid backup — with one honest caveat, worth flagging now and covered properly in sqlite1-5: it's only safe to copy the raw file this simply when no write is currently in progress.

The C Library, Linked Directly

SQLite is written in C and either compiled directly into an application or loaded as a shared library the application links against. Application code written in Python, Node.js, Java, or any other language uses a language-specific binding that ultimately calls into this same underlying C library. This is exactly why there's no separate "connection" step in the client-server sense — "connecting" to a SQLite database really just means opening the file through the library, an operation that completes almost instantly, since no network handshake or authentication step is involved at all.

This Course's Own Throughline

Evaluating SQLite as "MySQL but smaller, or weaker" is a category error — it isn't attempting to solve the same problem MySQL and Postgres solve. MySQL and Postgres exist to let many separate applications or processes, potentially on different machines, share reliable, concurrent access to the same data over a network. SQLite exists to let a single application embed a real, full-featured, ACID-compliant database directly into itself, with zero server infrastructure required at all. The real question this course keeps returning to isn't "which database is better" — it's "does this application need a server at all."

Hands-On Exercises