You can now sketch tables and relationships on paper. This lesson gives that design a home: a real database that survives restarts, serves many users, and answers precise questions. The durable concept is PostgreSQL. The convenient starting paths are Supabase and Neon. Learn them in that order — concept first, dashboard second.

PostgreSQL is the concept; the rest is operations

PostgreSQL — Postgres for short — is a widely used open-source relational database. It stores tables exactly like the ones you sketched, enforces types and relationships, and answers SQL queries (Class 21). It has been refined for decades, which is why it is the default answer to "where should a small application's structured records live?"

Start with the official PostgreSQL tutorial on tables: creating a table, declaring column types, adding constraints. You do not need to run a server today. Read it as the definition of the ideas from Lessons 20.1 and 20.2 expressed in the database's own language — CREATE TABLE, column types, primary keys, foreign-key references. Everything else in this lesson is a different way of *operating* that same concept.

Running Postgres yourself means installing it, patching it, backing it up, scaling it, and securing access. That is a profession, not a prerequisite. A managed Postgres service has another company operate that infrastructure so a beginner can focus on schema and product work. You still own your data model, your access rules, and your backup policy.

Two starter paths, no winner

This course presents two managed paths because they teach different lessons about the same database. Neither is "the best." Pick one primary database per project — collecting databases like browser tabs is how records diverge and provenance dies.

Read the contrast carefully. Supabase answers "I need a backend quickly": users can sign in, files have somewhere to live, and the tables from Lesson 20.2 are queryable through a dashboard and an API without building a server first. Neon answers "I want Postgres with modern database workflows": each git branch can get its own database copy, so experiments and agent-generated migrations run against a clone instead of production.

A travel planner with accounts and saved itineraries leans Supabase. A Sonariq prototype testing risky schema migrations with an AI agent leans Neon. Either choice runs the same tables, types, foreign keys, and SQL you learn next class. The concept transfers; only the dashboard changes.

One primary database, worked safely

Whichever path you choose, four rules keep a beginner out of trouble — and they connect directly to Part V, where you learned to operate CLIs and guard credentials:

1. One primary database per app. User records, reports, evidence, and saves live in one Postgres. A second database is a second source of truth, a second backup story, and a second access policy. Split only with a measured reason — scale, regulation, or a workload Postgres genuinely cannot serve — not because two dashboards looked interesting. 2. Drive it through an authenticated CLI, but plan before executing. Both paths offer one: Supabase's supabase CLI and Neon's neonctl let you — and your coding agent — create projects, run migrations, and query a real database from the terminal. From Part V you already know the bargain: credentials live in environment variables, never in chat or committed files, and every command that changes state gets a stated plan first. 3. Every migration gets review. A *migration* is a versioned script that changes the schema — creating evidence_items, adding status to reports — applied in order, not a hand-edit in a dashboard. The safe agent workflow: agent drafts the migration from your approved sketch → you read the plan → it applies to a development database → you verify → only then does it touch anything shared. The human defines the row and the relationship (Lesson 20.2); the agent writes the syntax. 4. Keep a safe first environment. Development is where experiments and agent drafts run. Production is where real users' records live. Never let Lesson-20 curiosity execute against production data.

Your sketch → agent drafts migration → REVIEW the plan
  → apply to dev/branch copy → verify tables + sample rows
  → only then consider shared/production

Dev vs. prod, migrations, backups, access — conceptually

Four production words, defined now at concept level; later parts of the course make them operational:

• Development vs. production: two separate databases with the same schema but different data. Dev holds disposable test rows and survives mistakes. Prod holds records users depend on and survives nothing casually. Neon's branching makes this vivid — a branch *is* a database copy — but the discipline applies on every platform.
• Migration: the ordered history of schema changes. Because schema evolves ("we added tags, we split sources out of evidence_items"), the database remembers *how it got here* as numbered scripts any environment can replay. Never "fix prod by clicking"; write the migration, test it on dev, then apply it forward.
• Backup: a restorable copy of the data, taken on a schedule and tested by restoring. Managed services automate the mechanics; you still own the questions: how much loss is acceptable, how long may a restore take, and when did we last prove a restore works.
• Access control: the rules for who — and which key, role, or service — may read or change which tables. Your owner_id columns from Lesson 20.1 only matter if the database enforces them: users read their own saves, writers edit drafts, nobody drops tables from a browser key. Supabase's auth integration exists precisely to connect sign-in with these row-level rules.

None of this requires production mastery today. It requires the mental slot: schema changes are reviewed scripts, environments are separated, copies are restorable, and access is designed rather than shared.

Check your understanding

1. What does a managed Postgres service operate for you — and what do you still own? 2. In one sentence each, when does Supabase's bundle fit, and when does Neon's branching fit? 3. Why should an app normally have one primary database? 4. What is a migration, and why must it run on dev before anything shared?

Worked choice: Sonariq prototype, Supabase vs. Neon

Apply the DATABASE-CHOICE.md template to one concrete project so the decision is a walkthrough, not a guess:

Sample project: Sonariq prototype (from Lessons 20.1–20.2)
Stage: prototype. No paying users; 1 builder + 3 test classmates.
  "Real users' data" = their saved reports — still disposable, must still be separated from dev experiments.
Users: sign-in needed soon (each tester saves their own reports), but not today.
Data shape: companies, research_reports, evidence_items + report_tags from Lesson 20.2.
  Questions: which reports belong to this company? which source supported this claim?
Owner: you (write your name). You approve every migration.

Decision path:

• Choose Supabase if this prototype needs accounts, saved-per-user rows, or file uploads next week. Reasons tied to this project: (1) testers each need a login and owner_id-filtered saves — Supabase Auth plus row-level rules cover that without a second service; (2) the team wants a dashboard SQL editor to inspect research_reports today and an auto-generated API tomorrow. First CLI command after creating the project: supabase init inside the project folder (creates the config), then supabase start for local dev — plan stated before running, credentials to env, never chat.
• Choose Neon if this prototype's risk is schema churn with an agent drafting migrations daily. Reasons tied to this project: (1) every risky migration runs on a branch copy (neonctl branches create --name agent-try-tags), so a bad ALTER TABLE breaks a clone, not shared test data; (2) data-heavy experiments (re-import filings, re-split sources) need disposable copies per branch. First CLI command after creating the project: neonctl auth (log in), then neonctl branches create for the dev copy — same plan-before-execute rule.

What safe first env looks like (either choice):

Dev database: sonariq-dev (Supabase dev project) OR main/agent-try-tags branch (Neon)
Prod database: none yet — test data only. Promote only with a reviewed migration.
Credentials: DATABASE_URL and (Supabase) SUPABASE_ANON_KEY live in .env.local,
  listed in .gitignore, never pasted into chat or committed.
Rule written in file: "no migration touches shared data without a reviewed plan."

What to click and read in the docs (do this before writing reasons):

• Supabase: open the database overview, click Tables in the left nav, read "Creating tables" and "Row Level Security" — confirm in your file how a table is created and how owner_id rules attach to Auth. Then open the dashboard SQL Editor page and note what a SELECT * FROM research_reports LIMIT 5; check looks like.
• Neon: open the introduction, click Branching in the left nav, read "Create a branch" — confirm a branch is a copy-on-write database clone and note the neonctl branches create command. Then read the "Connect" page for where DATABASE_URL comes from.
• Paste both docs URLs you actually read into DATABASE-CHOICE.md. A reason without a URL is a rumor.

For this sample project the course picks Supabase first (testers + saves need Auth soonest), with Neon branching as the second tool when agent-driven migrations get risky. Your project may flip — the walkthrough above is the method: stage, users, data shape, owner, first CLI command, safe env, two verified docs facts.

Exercise: write your database choice

Create a DATABASE-CHOICE.md file for a sample project — your research app, trip planner, or support assistant:

• Stage: prototype, private beta, or learning exercise — and what "real users' data" means for this project.
• Data needs: the three tables from Lesson 20.2 and which questions they answer.
• Choice: Supabase or Neon, with two specific reasons tied to *this* project's needs — not "it is popular."
• Owner: who approves schema changes (you, for now — write the name).
• Safe first environment: dev project or branch name, where credentials live (env file, never committed), and the sentence "no migration touches shared data without a reviewed plan."

Finish line: a one-page DATABASE-CHOICE.md a teammate could read and enforce without asking you anything.

Verify: open the official docs page for your choice and confirm two facts you relied on — a feature, a limit, or a CLI command. Paste the docs URLs into the file. If a claim has no URL, it is a rumor, not a reason.

Common failure: choosing "both, to compare later" and running two databases with diverging schemas. Comparison is reading docs and picking one; running two primaries is how Lesson 20.1's provenance guarantees go to die.

What comes next

Class 20 gave you durable memory: what a database is, how to shape its tables, and where Postgres lives. Next, Class 21 teaches SQL — the precise question language, read-only first, with AI drafting syntax while you own the question and the safety check.