Database

SyntaxKit uses PostgreSQL via Prisma, owned by packages/database. Bring any Postgres you like: a hosted provider such as Neon, Supabase, or RDS, or one you run yourself with Docker. The same DATABASE_URL switches the app between them, and the Prisma client picks the right driver adapter automatically.

Choose a Postgres

Point DATABASE_URL at a hosted provider or a local Docker container.

Schema layout

How the Prisma schema is split across domain files.

Common workflows

Migrate, reset, seed, inspect, and regenerate the client.

Migrations in production

The non-interactive migrator and how to run it safely.

Choose A Postgres

DATABASE_URL="postgresql://<user>:<password>@<host>/<database>"

docker run --name syntaxkit-postgres \
  -e POSTGRES_USER=postgres \
  -e POSTGRES_PASSWORD=postgres \
  -e POSTGRES_DB=syntaxkit \
  -p 5432:5432 \
  -d postgres:16

DATABASE_URL="postgresql://postgres:postgres@localhost:5432/syntaxkit"

Schema Layout

The Prisma schema is split across several files in packages/database/prisma/ so each domain has a clear home:

What's Modeled

How The Models Connect

The diagram below shows the foreign-key relationships across the four domains.

The diagram source lives at apps/docs/diagrams/database-erd.mmd. Rerun pnpm --filter @syntaxkit/docs diagrams:build after editing it to refresh both SVG variants.

Two patterns are worth calling out: every product entity (Subscription, Chat, AiUsageEvent) is scoped to an Organization rather than a User, and User is wired into orgs only through Member. That is what makes SyntaxKit multi-tenant by default.

Common Workflows

Expand the task you're doing.

pnpm db:migrate:dev

pnpm db:migrate:dev

pnpm db:reset

pnpm db:reset:demo

pnpm db:studio

pnpm db:generate

pnpm auth:generate

Using The Client In Your Code

Import the singleton client from @syntaxkit/database and write Prisma queries the usual way:

import { prisma } from "@syntaxkit/database";

const orgs = await prisma.organization.findMany({
  where: { members: { some: { userId } } },
});

prisma is a process-wide singleton. The driver adapter is chosen for you based on DATABASE_URL (Neon serverless when the host ends with .neon.tech, standard pg everywhere else), so your application code never has to know which Postgres it is talking to.

Migrations In Production

Production deploys use the non-interactive migrator:

pnpm db:migrate:deploy

Two important details:

• The migrator service in docker-compose.yml runs this command for self-hosted Docker deploys. Run it before bringing up web after every schema change.
• pnpm db:migrate:status reports whether the database is in sync with the migrations directory; useful in CI and on deploy targets that do not auto-migrate.

For platform-specific runbooks (Vercel, Fly.io, Render, Docker), see Deployment and Going To Production.

Seeding

prisma db seed runs through packages/database/prisma/seed.ts, which dispatches to one of three modes:

Where To Go Next