5 posts tagged with "postgres"

Supabase is a great way to get a PostgreSQL database running in minutes. But as your project grows, you often outgrow the auto-generated migrations and want more control over exactly what SQL runs against your database. PostKit gives you that control — full schema-as-code, session-based migrations, and a deploy pipeline you can reason about.

This guide walks you through bringing a Supabase project into PostKit's migration workflow without disrupting your existing data.

Most database migration tools work the same way: write some SQL, run it against the database, hope for the best. PostKit takes a different approach — before any migration runs, we clone the production database to a local copy and work against that. It sounds like extra overhead. In practice, it catches a category of bugs that no amount of unit testing can find.

PostgreSQL schemas are namespaces inside a single database. Most applications start with just public and never think about it again. But as applications grow — multi-tenant SaaS, microservices sharing a database, strict separation between application and audit data — you eventually want multiple schemas. And then the tooling usually falls apart.

PostKit handles multiple schemas natively, with a clear model for what goes where.

There are two schools of thought on database migrations. The first says: write every ALTER TABLE by hand, accumulate them as numbered files, and replay them in order. The second says: declare the desired schema state, let a tool figure out what SQL to generate. PostKit uses the second approach. Here's why.

Prisma is an excellent ORM and Prisma Migrate is a good solution for teams that want to stay in TypeScript and never write SQL. But some teams reach a point where they want direct SQL control — complex views, functions, triggers, RLS policies, custom indexes. Prisma Migrate's model makes these awkward. PostKit is built for exactly that use case.