Getting a Database Running on Your Machine
Websites need persistent storage. Blog posts, user profiles, and orders live in a database — not in React source files at runtime. Your UI asks a server; the server reads rows from PostgreSQL.
Three tools form the typical local stack — see Vocabulary below.
Vocabulary
| Term | Meaning |
|---|---|
| PostgreSQL | Relational database — tables, columns, relationships |
| Docker | Runs Postgres in a container — no manual install |
| Prisma | TypeScript ORM — typed queries, migrations, schema file |
| Migration | Versioned SQL change applied to the database schema |
| Seed script | Script that loads starter or demo rows after migrations |
Steps
Step 1 — Start Postgres locally
Copy your env file and run a compose stack that starts the database and app together:
Your connection string looks like:
Step 2 — Define models in schema.prisma
This is the blueprint the whole team shares:
Run yarn db:migrate to generate SQL and apply it:
Step 3 — Generate the client
Prisma creates a typed client. Use a singleton so dev hot-reload does not spawn new connections:
Step 4 — Seed starter data
A seed script wipes and reloads demo content from TypeScript arrays:
Run: yarn db:seed. Browse rows with yarn db:studio.
Common pitfalls
- Editing the database manually without a migration — teammates' schemas drift.
- Running
migrate devin production — usemigrate deployinstead. - Forgetting
db:generateafter schema changes — TypeScript types go stale.
Verify it works
Open Prisma Studio. You should see seeded rows. Change a model, run migrate, confirm the column appears.
Takeaway
Schema file defines structure. Migrations version changes. Seed loads content. Prisma client gives you typed access — Docker gives you Postgres without installing it.