Thin Backend Services: Azure vs. Paying for Prisma

TL;DR for security + simplicity

• Stay on Azure. Use one managed Postgres instance as source of truth.
• Use Prisma as an OSS, in-process ORM for type safety and migrations. You don't pay Prisma unless you turn on their optional cloud services.
• Avoid a custom data layer; it creates more surface area without adding security.

Options, ranked for this project

1) Azure managed Postgres + Prisma (recommended)

• Security: Single ingress (Postgres) behind Azure firewall/privileged identity; Prisma runs inside the app so no new public surface.
• Simplicity: Schema lives in code, migrations are deterministic, types generated automatically; least cognitive load for a thin backend.
• Cost: Only Azure bill. Optional Prisma Accelerate/Data Platform are paid—skip until needed.

2) Azure managed Postgres without an ORM

• Security: Same as above.
• Simplicity: Fewer dependencies but more handwritten SQL and manual migrations; more footguns and drift risk.
• When to pick: You already have strong SQL discipline and migration tooling, and you want zero extra runtime deps.

3) Custom-built data/service layer

• Security: More bespoke code paths and auth logic to audit; larger attack surface.
• Simplicity: Highest complexity; you'd reinvent migrations, pooling, and query helpers.
• When to pick: Almost never for this scope.

How Prisma affects the surface area

• Prisma Client is compiled into the backend—no public endpoint, no new auth boundary.
• Use Azure-managed identity or Vault-stored connection strings; Prisma respects whatever the `DATABASE_URL` uses.
• If you later enable Accelerate (for pooling/edge), treat it like any gateway: lock allowed origins and monitor usage.

Minimal deployment recipe

• Azure Database for PostgreSQL (backups on, private access if possible).
• Next.js API routes (or Azure Functions) with Prisma Client and migrations.
• Optional edge caching for read-mostly persona slices; no extra vendors required.

Decision rule

Start with Postgres + Prisma OSS. Re-evaluate only if you (a) need pooling at scale (then consider Accelerate) or (b) have a team that insists on raw SQL and already has migration discipline. Anything more custom increases risk without payoff for this site.