Database

The dual-database model

Genesis uses Prisma with a deliberate split:

• Development: SQLite (DATABASE_URL=file:./dev.db), zero configuration, nothing to install
• Production: PostgreSQL via the native pg adapter, or SQLite on a persistent volume for small deployments

The schema and every query are identical in both. Only the connection configuration changes.

The maximal schema

prisma/schema.prisma ships with all anticipated models from day one: users, sessions, accounts, verification, feature flags with overrides and usage tracking, chat messages, uploads, and newsletter subscribers. The template philosophy is to prune what you do not need rather than bolt on as you go; models for stripped modules can be deleted with their module.

Day-to-day commands

bun run db:push       # push schema changes to the database (pre-migration phase)
bun run db:seed       # create demo accounts and data
bun run db:fresh      # reset the database and reseed
bun run db:generate   # regenerate the Prisma client after schema edits

The seed creates two accounts for local work:

• admin@genesis.template / Password1 (admin role)
• user@genesis.template / Password1

Going live: migrations

Pre-launch, db:push keeps iteration fast. Once you have production data, switch to migrations:

bun run db:migrate    # create a migration in development
bun run db:deploy     # apply pending migrations in production

Baseline with an initial migration at launch and use db:deploy in your release process from then on.

Local Postgres

docker-compose.dev.yml provides a local PostgreSQL container when you want production parity in development. Point DATABASE_URL at it and the same code runs unchanged.