Why we chose Postgres + Prisma over the rest

When we picked the BuildFlow stack, the temptation was to chase what's hot — distributed SQL, a fancy edge runtime, a NoSQL store with a marketing budget. We picked Postgres and Prisma. Here's the boring reasoning.

Postgres because we are not Google

BuildFlow will, plausibly, never have a workload that one well-tuned Postgres can't handle. Multi-region distributed SQL is a great answer to a question we don't have. A single primary with read replicas, partitioned tables for the audit log, and pgvector for AI insights is enough.

Prisma because schema drift is the slow killer

We've all worked in codebases where the database and the type definitions slowly diverged. Prisma's generated types and migrations keep us honest. Prisma is not perfect — its query patterns sometimes need raw SQL escape hatches — but its drift-prevention property is worth the trade.

• Single source of truth: schema.prisma
• Generated types in CI block builds when the schema drifts.
• Raw SQL is allowed and audited — we don't pretend we don't need it.

What we'd avoid telling our past selves

Don't fight the stack to look modern. Boring tools with sharp edges beat exciting tools with dull ones. Every hour we didn't spend re-implementing a join was an hour we spent on the audit log, the AI pipeline, or the part of the product the customer actually sees.