Database

Spacerr uses Neon Postgres with Prisma by default. The database stores users, auth records, chats, messages, projects, files, blog posts, support tickets, billing access state, settings, and admin related product data.

Why Neon

Neon is the default because it is free to start, serverless, and easy to use with Vercel.

• It is Postgres.
• It works well with Prisma and Vercel.
• It can scale automatically as your app grows.
• It can scale down when your app is quiet, so early startups do not pay for idle database capacity.
• It gives you pooled runtime URLs and direct migration URLs.
• It makes preview, local, and production databases simple to manage.

Neon is a default, not a lock in. The app uses Prisma, so you can switch to another Postgres provider later.

Schema Layout

The Prisma schema is split by domain so each part of the product has an obvious home.

prisma/schema
  base.prisma
  auth.prisma
  user.prisma
  ai.prisma
  blog.prisma
  support.prisma

base.prisma contains the generator and datasource. Domain files contain the actual models and enums.

Use the domain file that owns the feature you are changing:

• auth.prisma for Better Auth tables.
• user.prisma for users, roles, account state, Stripe customer data, and purchase state.
• ai.prisma for chats, messages, projects, source files, library files, and AI tool records.
• blog.prisma for blog posts.
• support.prisma for support tickets.

Prisma Client

The generated Prisma client lives under src/generated/prisma.

generator client {
  provider = "prisma-client"
  output   = "../../src/generated/prisma"
  runtime  = "vercel-edge"
}

Server code imports Prisma runtime types and the client from server safe modules. Client components that only need types should import browser safe generated types from @/generated/prisma/browser.

Local Workflow

Install dependencies, generate the client, then run the local migration workflow.

bun install
bun db:generate
bun db:migrate

bun db:migrate runs Prisma migrate in development mode and regenerates the client afterward.

Use Prisma Studio when you need to inspect local data or promote your first admin user.

bunx dotenv -e .env.local -- prisma studio

Production Workflow

Production should use committed migrations. Do not use development migration commands against production data.

Use this command when applying committed migrations in production.

prisma migrate deploy

The project also includes a postinstall script that runs migration deploy and regenerates the Prisma client during install.

{
  "postinstall": "prisma migrate deploy && bun db:generate"
}

If you change how your host runs installs and builds, keep the same idea: deploy committed migrations, then generate the Prisma client before the app builds.

In production, use the production Neon project or your production Postgres provider. Keep production migration deploy separate from local migrate dev usage.

Postgres Extensions And Source Search

The AI workspace source search uses normal Prisma indexes plus Postgres trigram indexes.

Normal Prisma indexes are defined in prisma/schema/ai.prisma. Source search uses userId, updatedAt, and id indexes so the app can quickly scan a user's recent files before ranking matches.

pg_trgm is a PostgreSQL extension that breaks text into overlapping three character chunks called trigrams. Postgres can use those chunks to speed up fuzzy and substring style search on text fields. In this app it helps search uploaded source records by:

• filename
• summary
• contentText

The source search migration also creates indexes like this:

CREATE INDEX IF NOT EXISTS "message_source_filename_trgm_idx"
ON "message_source" USING GIN ("filename" gin_trgm_ops)
WHERE "filename" IS NOT NULL;

This is PostgreSQL specific. Neon supports it, and many managed Postgres providers support it, but non Postgres databases such as MySQL or SQLite do not. Some Postgres hosts may also require extension creation to run with a privileged migration role.

If you ever squash or delete migration files and recreate a new INIT migration, do not lose this extension setup. Copy the CREATE EXTENSION IF NOT EXISTS pg_trgm; line and the source search trigram indexes into the new init migration. If you forget, the app can still store files, but source search will be slower and the trigram indexes will not exist.

Admin User

Create the first user through the normal sign up flow, then promote that user in the database.

Set the user's role to admin in the User table through Neon or Prisma Studio.

role = admin

After that user signs in again, the admin dashboard and protected admin actions are available.

If You Want To Switch From Neon

First check the Prisma supported databases, then follow the Prisma guide for the provider you want to use.

For this app, the main things to update are:

1. Replace DATABASE_URL with the new runtime connection string.
2. Replace DIRECT_URL with the new migration connection string if your provider needs one.
3. Update src/lib/prisma.ts if the new provider needs a different Prisma adapter or connection setup.
4. Run the normal Prisma generate and migration workflow.
5. Deploy with the new production env vars.

If you stay on Postgres, most product code does not need to change because feature repositories talk to Prisma, not Neon directly.

If you move away from Postgres, follow Prisma's provider specific migration notes carefully because field types, indexes, relations, migrations, and adapters can change.