Setting Up Your Lab

Good news: your lab is already set up. Every lesson on this site ships with a real PostgreSQL database running live in your browser — nothing to install, nothing to configure, nothing you can permanently break. This lesson shows you how that lab works, then walks through the tools you'll want on your own machine when you're ready — because knowing how to install and connect to a database is itself a skill the course promises you.

The in-browser playground (used all course)

Every playground on this site is the real thing: PostgreSQL 18, compiled to WebAssembly, running privately in your browser tab. Not a simulator, not a subset — the same engine you'd install on a server, producing the same grids, the same error messages, and (in Part IV) the same query plans. Three things to know about how it behaves:

• Run rebuilds the world. Each playground comes pre-loaded with the lesson's tables. Every time you press Run, the database is rebuilt fresh from that starting point, then your SQL runs top to bottom. Delete every row, drop every table, run again — it's all back. Experiment fearlessly; the reset is the safety net.
• The sql> prompt continues where Run left off. Below most playgrounds is a console prompt. Statements you type there run against the database as your last Run left it — perfect for poking at results. (A friendliness note: the prompt runs whatever you type when you press Enter, semicolon optional. Real psql — below — insists on the ;.)
• The schema bar shows your tables. The strip above the editor lists every table with its columns and live row count, and updates as you work. When you CREATE TABLE in Section 9, watch it appear there.

One honest limitation worth knowing early: your lab is a single-user database — one session, yours. Real servers juggle thousands of simultaneous sessions, and the handful of behaviors that only exist between two sessions (Section 12's concurrency dramas) will be shown as annotated transcripts instead of live runs. Everything else in this course runs for real, right here.

Installing PostgreSQL locally — and why we teach Postgres

You don't need this today. Bookmark it for when you do.

This course teaches on PostgreSQL because it's open source, scrupulously standards-respecting, feature-rich enough to carry you from first SELECT to production tuning — and because it's consistently the most-loved and most-wanted database in developer surveys. What you learn here transfers; Section 20 maps the differences to every major engine.

• macOS: the one-command route is Homebrew —

brew install postgresql@18
brew services start postgresql@18

• Windows: the EDB installer from postgresql.org (check "Command Line Tools"), or winget install PostgreSQL.PostgreSQL.
• Linux: your package manager (apt install postgresql / dnf install postgresql-server), or the postgresql.org repos for the newest major version.

Every install includes psql, the command-line client you'll meet across the course's transcripts. Connecting looks like this:

$ psql -U postgres
psql (18.3)
Type "help" for help.
 
postgres=# SELECT 1 + 1;

That postgres=# prompt is psql waiting for SQL — the desktop cousin of this site's sql> prompt. psql also has its own meta-commands, which start with a backslash and are not SQL — \d lists tables, \q quits. They work only in psql (try \d in a playground here and it will politely decline); the pure-SQL way to inspect your schema, which works everywhere, comes in Section 9.

SQLite: the database already on your machine

SQLite takes the opposite trade from Postgres: no server at all. The entire database is one file, and the engine is a small library that apps embed directly — which is why it's already inside your phone, your browser, and most desktop apps you own. It's the right tool for local apps and quick experiments, and you likely have its shell today:

$ sqlite3 cafe.db
SQLite version 3.46.1
sqlite> CREATE TABLE notes (id INTEGER PRIMARY KEY, body TEXT);

Same language, different accent — SQLite is looser about types (Section 3.1 tells that story). Knowing it exists completes your mental map: Postgres for servers and serious apps, SQLite for embedded and local.

DuckDB: the analyst's new favorite

DuckDB is SQLite's shape (in-process, single file, zero setup) pointed at the opposite job: crunching analytical queries over big files, absurdly fast. duckdb in a terminal, then SELECT … FROM 'sales.parquet' and you're querying a half-gigabyte file in place. It shows up properly in Part V's analytics track (17.4), along with the warehouse world it miniaturizes.

GUI clients vs. the raw shell

psql is powerful but spartan. When you want your queries, results, and schema on one screen: pgAdmin (free, Postgres-specific), TablePlus (polished, multi-engine), DBeaver (free, connects to everything), or your editor's database panel (VS Code, JetBrains). All of them are windows onto the same engine — pick whichever keeps you comfortable. The skill that transfers is the SQL, not the chrome around it.

Loading the course's sample database

On this site, nothing to do — every playground pre-loads its lesson's data, and each milestone project brings its own richer database. When you later want a course dataset inside your local Postgres, Section 8.4 teaches exactly that (COPY — bulk-loading from files), and the capstone has you load a messy real-world dataset from scratch. Until then, the lab travels with the lessons.

Setup complete — you carry a database in your browser and know where the desktop tools live. Next lesson, you finally get to say something to it: your first SELECT, and how to read what comes back.