← All notes

Two apps, one Neon database

BuddingPlanted Jun 26, 2026Last tended Jul 19, 2026postgresneondrizzlemonorepo

Two apps, one Neon database

My monorepo has two independent Next.js apps that both need Postgres. Instead of provisioning a second Neon project, they share one database. Two rules make that safe:

1. Prefix your tables. Every table the second app owns starts with booking_:

export const services = pgTable("booking_services", { /* … */ });
export const bookings = pgTable("booking_bookings", { /* … */ });

The two apps' tables coexist in one schema, stay visually grouped in any DB client, and remain cross-readable if one app ever wants to query the other's data.

2. Never db:push on a shared database. This is the one that bites. Drizzle's push diffs the entire database against your schema file — and your schema file doesn't know about the other app's tables. From push's point of view they are drift to be removed. One convenient command, and the neighbour app's tables are gone.

The safe loop is generate + migrate:

pnpm -F booking-service db:generate   # writes drizzle/0002_*.sql from the schema diff
pnpm -F booking-service db:migrate    # applies exactly that file, records it

Migrations are versioned SQL you can read before they run, they only touch the tables they mention, and the migration folder doubles as a diary of every schema change the app ever made. push is fine for a throwaway solo database; the moment a database is shared, it's migrate or nothing.

Related: the same app taught me to never throw at module load when the database isn't provisioned yet.

Linked from

  • Never throw at module load in Next.js

    next build imports your modules with production NODE_ENV but none of your runtime env. A top-level throw on a missing env var kills the whole build. Degrade instead.

  • An Obsidian vault as a cross-tool AI external brain

    One markdown vault as the shared memory for every AI I work with — coding agents read and write it natively, web chats bridge in via a paste ritual. The rules that keep it from rotting.

Related notes

  • Git worktrees + hoisted pnpm: where did my binaries go?

    A git worktree is a fresh checkout — it has your files, not your node_modules. With pnpm's hoisted linker every tool binary lives at the original repo root, so eslint/vitest/next simply don't exist in the worktree.

  • TIL: Postgres websearch_to_tsquery

    Postgres ships a full-text query parser that understands Google-like syntax out of the box — quoted phrases, OR, and -exclusions — no hand-rolled parser required: