Skip to main content
Engineering

Getting a Database Running on Your Machine

9 min read

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:

bash

Your connection string looks like:

bash

Step 2 — Define models in schema.prisma

This is the blueprint the whole team shares:

prisma

Run yarn db:migrate to generate SQL and apply it:

sql

Step 3 — Generate the client

bash

Prisma creates a typed client. Use a singleton so dev hot-reload does not spawn new connections:

typescript

Step 4 — Seed starter data

A seed script wipes and reloads demo content from TypeScript arrays:

typescript

Run: yarn db:seed. Browse rows with yarn db:studio.

Common pitfalls

  • Editing the database manually without a migration — teammates' schemas drift.
  • Running migrate dev in production — use migrate deploy instead.
  • Forgetting db:generate after 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.