Keep your database schema typed and your SQL migrations checked in beside the code that needs them.

8 files · 8 KB

Drizzle ↗

Why I keep it

I keep WithSeismic’s Postgres schema in packages/db, so the apps import one database package. Drizzle turns schema changes into SQL migrations I can read and commit. The API applies them before a deployment starts, so a new version meets the tables it expects.

Some rules belong in the database itself, so I’ve included the starter’s SQL trigger that protects an organisation’s last owner. You also get the pool setup, schema exports, Drizzle config and migrate script: the pieces for making database changes part of the release.

Take the files

8 files · 8 KB

  • README.md3 KB
  • drizzle/0001_owner-guard.sql1 KB
  • drizzle.config.ts303 B
  • package.json599 B
  • scripts/migrate.ts481 B
  • src/index.ts569 B
  • src/schema/index.ts185 B
  • src/schema/organizations.ts2 KB

Keep building your setup: The stack

Back to the shelves →
  • 015 files · 151 KB

    The SaaS starter

    Start with accounts, organisations, email and analytics wired into a React app and Hono API.

  • 025 files · 6 KB

    Turborepo

    Run builds, tests and type checks across your apps in dependency order, with cached results.

  • 0316 files · 18 KB

    Hono

    Give your API typed routes, generated docs and a consistent error response before adding features.

  • 042 files · 5 KB

    Better Auth with passkeys

    Keep accounts, organisations and passkey sign-in in your own Hono API and Postgres database.

  • 059 files · 10 KB

    TanStack

    Keep React routes, session checks and cached server data working from the same types.

  • 065 files · 5 KB

    Lefthook and Biome

    Check staged code at commit time and types before a push, including work written by your agents.