Every time I tweet that I'm using Postgres + Prisma for a new product, someone tells me I should use X. Drizzle. Bun's SQLite. Turso. PlanetScale. SurrealDB. And the arguments are always valid on some theoretical plane. But after three VantLabs products built on Postgres + Prisma, my conclusion is that boring is a feature.
The "Prisma is slow" argument
It's true. Prisma has overhead vs a raw Postgres driver. In artificial benchmarks, a simple query is 30-40% slower. In real production, with queries that hit disk, indexes and network, that difference dilutes to the point of irrelevance: 4ms vs 6ms for most queries a normal product writes. If your product is hot enough that those 2ms matter, you're not writing SaaS — you're writing infrastructure, and Prisma isn't for you.
For everything else, Prisma gives me the kind of productivity that justifies those 2ms ten thousand times a day: auto-generated types, declarative migrations, autocomplete that knows which columns exist, and a single schema that is the source of truth for both the database and the TypeScript client.
The "Drizzle is better" argument
Drizzle is excellent. It has the opposite mental model from Prisma: instead of an ORM with its own query DSL, it gives you a query builder that feels like SQL written in TypeScript. For someone who already thinks in SQL, Drizzle is probably faster to write and easier to optimize.
But for a solo founder, there's an invisible Prisma advantage few comparisons mention: the ecosystem. NextAuth has an official Prisma adapter. Inngest, Trigger.dev, and most serverless platforms have integrations. When something breaks at 11pm on a Friday, there are 12 thousand Stack Overflow results and 30 open issues discussing the exact case. Drizzle has all of that but newer, which in practice means fewer Google answers and more lonely debugging.
The "MongoDB is simpler" argument
I've heard it every year since 2012 and every year it seems more wrong. MongoDB is simpler for writing the first model. It's more complex for everything else: relations, joined queries, aggregations, referential integrity, migrations, backup. Postgres with JSONB columns gives you 90% of Mongo's flexibility when you need it (semi-structured data), and 100% of relational rigor when you need it (everything else).
In any serious SaaS product you have a dozen distinct entities with real relations between them: accounts, sessions, transactions, generated resources, audit logs, queued jobs. All of that needs transactional consistency. Postgres does it in a single database with queries a junior can understand. Mongo forces you to denormalize by hand and suffer every time a user reports something that doesn't add up.
The "you should use Edge functions with Turso/PlanetScale" argument
Turso is brilliant for apps needing minimum latency to globally distributed users. PlanetScale is brilliant for absurd scale with automatic sharding. But ReclamaAI mainly serves Colombian users. Serverless functions run in us-east, database in us-east, users are in Colombia (base latency ~100ms to us-east). Winning 30ms by switching to edge moves nobody's needle.
The rule I follow: optimize for developer time, not for latency, until latency becomes a real bottleneck measured by real users. Today my bottleneck is Claude's response time (3-8 seconds per document), not Postgres latency. Optimizing Postgres at the cost of operational complexity would be fixing the wrong problem.
The real cost of a trendy stack
Every time you adopt a trendy stack, you're paying an invisible tax: less documentation, fewer forum answers, more undiscovered bugs, fewer mature integrations, and a higher chance the project gets abandoned or radically changed in 2 years. For a company with a team, that tax can be worth it for a competitive edge. For a solo founder, it's almost always a bad bet.
Postgres is 30 years old. Prisma is 7 and stable. The combination is exactly boring. It doesn't make me look smart on Twitter. It lets me build products.