Database

Local database

docker compose up -d starts PostgreSQL in a container, exposed on host port 3377 (mapped to the container's internal 5432). Your local DATABASE_URL points at this container.

The Prisma schema is split across prisma/schema.prisma plus per-model files under prisma/models/ (one file per domain area: shops, forum, invite, categories, products-and-services, events, surveys, websites, and more). Because of this, most prisma CLI commands need --schema ./prisma to see the whole model set. The db:* scripts in package.json already include the flag:

pnpm db:gen      # prisma generate --schema ./prisma
pnpm db:pull     # prisma db pull --schema ./prisma
pnpm db:push     # prisma db push --schema ./prisma
pnpm db:migrate  # prisma migrate deploy
pnpm db:studio   # prisma studio --schema ./prisma

Prefer these scripts over raw prisma calls.

Migrations are a partial history

prisma/migrations/0_init is a large, single baseline migration (over 1,300 lines of SQL) generated from the schema as it existed at the time — not an incremental history of every change ever made. Only a handful of migrations have been created since (e.g. the better-auth cutover, product_public_by_default, shop_is_public, platform_invite_shop_attachment).

For your own local database, pnpm db:push is fine — that's how the schema baseline itself was produced, and it's the recommended way to sync your local DB during day-to-day development. Never run prisma migrate reset against a shared database (anything other than your own local container) — it drops and recreates the schema, destroying data other people or projects depend on.

Schema changes deploy via db push

Staging and production are managed with prisma db push, not prisma migrate deploy — including the product-sync schema (prisma/models/product-sync.prisma, migration 20260730120000_product_sync). Migration files under prisma/migrations are kept around as documentation of intent, not as a history that gets replayed against those databases. Don't run pnpm db:migrate against staging or production; use db:push to apply schema changes there, consistent with how the rest of the schema has always been deployed.

Shared with UPCY

The default local database (mydatabase, per docker-compose.yml) is shared with the UPCY project, primarily for authentication — UPCY also keeps its own separate database for upcycle-specific entries. Keep the postgres-data Docker volume consistent across both repos (or point both at the same running container) to avoid schema drift, and don't wipe it casually.

The af_docs database

The docs screenshot pipeline (see Docs maintenance) uses a dedicated af_docs database on the same local container, created via prisma db push and holding only docs demo data. It's kept separate from mydatabase specifically so the docs pipeline can never collide with or corrupt the UPCY-shared dev database.

Seeding

prisma/seed.ts seeds categories only — it wipes all existing categories (and disconnects them from every product) before recreating them from prisma/category-data.ts. It runs through Prisma's seed hook (the prisma.seed field in package.json, tsx prisma/seed.ts), invoked directly:

tsx prisma/seed.ts
# or
prisma db seed

This script is destructive to the Category table and dev-only. Don't run it against a database anyone else depends on.

There is no pnpm db:seed script — this is the only entry point for that seed.

Production data import

Production data can be pulled down for local use in two steps:

Export — pnpm db:export-prod (scripts/export-production.ts) is a read-only script that runs SELECT-only queries against PROD_DATABASE_URL and writes production-export.json. You can pass specific table names as arguments to export a subset.
Import — load that export through the admin Fork import tool (src/app/admin/fork-import/), which is designed to bring production data into a local/fork environment safely.