The thesis: the database engine is the easiest decision in the stack and founders keep treating it as the hardest. Use Postgres. The decisions that actually matter are which host, which ORM, and how tenant isolation is enforced, and only the last one is genuinely dangerous to get wrong.
Use Postgres, and here is why that is not lazy
- Argue from three angles: operational maturity, ecosystem breadth, and the fact that it is overwhelmingly represented in agent training data.
- Name the narrow cases where something else is correct: heavy analytics, genuine document workloads, edge-first read patterns, and be specific about the threshold.
- State the corollary: choosing a novel database now costs more than it did, because every generated query inherits the model's weaker priors.
The hosting decision
Serverless Postgres (Neon and similar)
- Strength: branching, scale-to-zero, cheap at low traffic, good fit for preview environments.
- Cost: connection pooling discipline, and cold start behavior worth understanding before launch.
Platform Postgres (Supabase and similar)
- Strength: database plus auth plus storage plus row-level security in one place, fast to start.
- Cost: coupling, and RLS is powerful but easy to half-implement.
Managed classic (RDS, Fly, Railway and similar)
- Strength: predictable, boring, no surprises at scale.
- Cost: more ops, less developer-experience polish, slower iteration on schema.
The ORM decision
- Frame the real trade: schema-first with generated client versus SQL-adjacent typed query builder.
- Argue what actually matters for an agent-heavy workflow is that the schema is a single readable file and migrations are checked in, because that file becomes the agent's map of your domain.
- Warn against mixing: one ORM, one query pattern, one migration tool, enforced in the agent brief. Link /templates/agents-md.
Multi-tenancy is the real decision
The three models
- Shared tables with a tenant column, schema per tenant, database per tenant. Give the honest fit for each and argue shared tables wins for almost every early SaaS.
Enforcement, not convention
- Argue the core point of the article: a tenant column that every query is supposed to filter on will eventually not be filtered on, especially when an agent writes the query.
- Push enforcement down: row-level security, or a repository layer where the tenant scope is impossible to omit. Fail closed.
- Cross-reference /blog/saas-auth-decision-guide for where identity ends and authorization begins.
What agents get wrong in the data layer
- Name the patterns: N+1 queries in loops, missing indexes on foreign keys they just created, migrations written but not run, and the tenant filter quietly dropped in a new endpoint.
- Argue the fix is structural rather than instructional: if the only way to query is through a scoped helper, the agent cannot skip the scope.
- Reference /blog/ai-agent-ready-boilerplate-checklist for the broader argument that structure beats prompting.
Schema decisions that are expensive to reverse
- List them: primary key type, soft delete versus hard delete, timestamps and timezone handling, and whether money is stored as integer minor units.
- Argue these should be decided by you on day one because every generated table copies whatever the first table did.
- Note the compounding effect: an agent will faithfully replicate your worst early decision across forty tables.
Migrations and the deploy story
- Argue migrations must be checked in, reviewable, and runnable in CI, because an agent that edits schema without a migration is a production incident waiting.
- Cover the preview-environment case, and why database branching changes how comfortable you are letting an agent touch the schema.
Frequently Asked Questions
Which database should I use for a new SaaS?
- Answer Postgres, then spend the answer on which host fits which situation.
Prisma or Drizzle in 2026?
- Answer by workflow rather than by benchmark, and say which one suits agent-written code better and why.
How should I handle multi-tenancy?
- Answer: shared tables with enforced scoping, and explain when per-tenant schemas actually earn their complexity.
Can I let an agent design my schema?
- Answer: use it to draft, never to decide, and explain what to check before accepting a generated migration.
Do I need Redis or a queue on day one?
- Answer usually no, name the two signals that mean yes, and warn against adding either preemptively.
